Have a look at the results in Portugal (this is a good summary https://en.wikipedia.org/wiki/Drug_policy_of_Portugal#Observ...) - then, come back here and tell us what evidence you've found of a slippery slope. I don't believe you'll be able to find any such evidence, because there is no such slippery slope in practice.
While it is OK for the government to make statements that portray things in a positive or negative light, it is not OK for them to do so in the absense of supporting evidence, or worse yet, in the presence of evidence to the contrary. The former is, charitably, called "marketing" - but the latter is more commonly known as "lying".
The Trump Administration has taken one of the most liberal positions on cannabis of any Republican president ever.
His stated positions on supporting states with medical laws, and his complete absence of federal raids on people following state cannabis laws, is very good for a republican president.
It's true that Trump has signaled for an end to the federal ban on marijuana, and that U.S. attorneys have since stopped targeting marijuana companies that are in legal states. However, this status quo was set by Obama-era rules (the "Cole memo" [0]). It's still up to President Trump to actually push through the legislation, which he has not been great at. But his public stance is definitely non-trivial, as it encourages those on the Republican side to support legislation that ends the federal ban, no matter what Attorney Sessions pushes for. Also, Sessions may at this point be seen as a lame duck anyway.
This analysis was done by BBVA comparing Tyk and Kong performance https://www.bbva.com/en/api-gateways-kong-vs-tyk/ - disclosure: I work for Kong, but Kong (the company) had no involvement with the benchmarking in that article.
Those BBVA benchmarks look very very wrong. BBVA achieved 3822 requests per second with a 16Gb server running Tyk.
I used a 16Gb Digital Ocean box, and a separate box to run benchmarks from.
Tyk CE with keyless api.
docker run --rm williamyeh/wrk -t4 -c100 -d1m --latency --timeout 2s http://10.131.45.89:8080/tykbench/get
Running 1m test @ http://10.131.45.89:8080/tykbench/get
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.79ms 6.97ms 206.76ms 87.28%
Req/Sec 6.35k 0.93k 10.89k 74.33%
Latency Distribution
50% 3.19ms
75% 6.28ms
90% 15.93ms
99% 31.14ms
1516573 requests in 1.00m, 185.13MB read
Requests/sec: 25244.99
Transfer/sec: 3.08MB
As per above results, I got 25,244 requests per second. 90% of requests were served with sub 15ms latency.
Another thing - you can freely scale with Tyk CE as much as you want at no-cost. I currently run 3 gateways in prod and it doesn't cost a penny. The BBVA article states that you need to pay Tyk to scale - simply not true:
>However, if we want to deploy a significantly larger number of microservices, or simply ensure high-tolerance to failure, we need to scale up the number of gateways. In the case of Kong, all it takes is adding a new node and connecting it to the database. With Tyk we can do the same, although it will require us to pay for the service. This could be a determining factor when choosing what API Gateway to use.
I went through process picking API gateway about 3 months ago. Tyk is not without it's warts, but has far more out-of-box features baked in (inc distributed rate limiting) than Kong. And if custom plugins are required, I can choose between lua, python, js or anything that supports gRPC. With Kong - stuck with Lua.... no thank you.
I guess my point here is that if Tyk not performant enough for you, just add another gateway. And if I need custom functionality - I don't need to learn Lua.
