We build Social Reech we got frustrated by the fact that several companies didn't reply to our tweets. Digging deeper, we found there we several complications of handling tweets. We build our platform on the basis of easing this process.
Not only managing tweets, we also handle if any of your company's name or keywords gets mentioned across the web. Our integrations include HackerNews, Reddit, Web Articles from across the web (we use a crawler).
We are also on process of launching our blog. There we'll be posting how we built this and our journey and the road acquiring customers.
Prefer Django, because it has so many things built in (authentication, other protections to build things super fast and not worry), many people call it magic but if you read the code, it's very easy to follow. [1] & [2] sites helped me a lot to remove the "magic" as well.
Prefer Vue because it is strongly opinionated, unlike other JS frameworks (i.e. React). Again, learning Vue allowed me to build things super fast and other having to worry about things like Gulp, Webpack and many more things that I don't understand in the JS community. Personally for me the JS community moves too fast for my liking and Vue has been a god send, especially with the help of Vue Cli [3]
Database of choice: PostgreSQL, because it is used by several developers rather than MySQL when building anything with Django.
Building realtime: I use a external service like Pusher or Pubnub, because they have generous free plans to get you up and running. But there is Django Channels if you don't want external dependency.
I'd say that Django is not a great fit for lambda. Lambda works best when you architect you code around it, with lots of tiny methods. Django does not encourage this way of coding (just like the other frameworks).
> Lambda works best when you architect you code around it, with lots of tiny methods
as a total hobbyist: why?
deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye.
that would've been my take why you'd want to use flask... because there is very little value in django if you remove models, caching, authentication, permissions and more (that can't be used without external infrastructure) from the equation.
I guess it depends on size of your app and expected load.
When your app is small and you got almost no users, zappa is great: your lambdas are lighting fast and you're in aws free tier.
When your app grows to like 200k SLOC and 50+ lines in requirements, chances are that it starts quite slow. Do you really want to pay for that?
When your load is high enough, well, aws lambdas become quite expensive even without zappa overhead compared to, say, EC2. https://servers.lol/ should say if serverless makes sense for any defined usecase.
Additionally, lambdas have hard restrictions (like 15 minutes limit) and sometimes it's a dealbreaker for you.
As a non-expert on lambda... Django encourages one function per view, and adding database calls, celery functions, maybe API calls, to your views make them quite big, and potentially slow to run. Running slow functions is not how lambdas are supposed to work (as I've understood them). Rather, you'd want smaller ones that call out to other smaller lambdas. That coding style is not something lambda encourages.
Yes, it's super cheap and simple. Check out serverless.com to get started. Run your vue/react/angular app on a S3 bucket, and then only handle the API calls on lambda functions. Pay only for what you use, and it's infinitely scalable.
Seconded on Vue. If you haven't used a frontend JS framework in a while, Vue will still be easy to pick up and learn. I love it. As for backend, Django, Rails, even .net core will do. Whatever you're most comfortable with.
Some routers and networks try to intercept all requests and replace them with a 'captive portal' page for logging into that network. When you make a request to a webpage using https:// (i.e. SSL) the network has a much harder time injecting the login page, so you end up seeing nothing. The connection isn't going through and the network's login page can't break through SSL battle-warrior-armor.
The scenario is: You want to connect to a public wifi hotspot and use their internet connection. In order to do so you need to trigger the login page in your browser after you connect to the hotspot.
However if you open common urls like google.com or facebook.com you'll automatically get redirected to secure connections (https) and they can't intercept this to present the login page. This is because TLS (the protocol behind HTTPS connections) uses end-to-end encryption.
Thus the author proposes to open this simple unprotected website. However most hotspots manage to automatically trigger the vendor specific mechanism as soon as you connect to their Wifi.
We build Social Reech we got frustrated by the fact that several companies didn't reply to our tweets. Digging deeper, we found there we several complications of handling tweets. We build our platform on the basis of easing this process.
Not only managing tweets, we also handle if any of your company's name or keywords gets mentioned across the web. Our integrations include HackerNews, Reddit, Web Articles from across the web (we use a crawler).
We are also on process of launching our blog. There we'll be posting how we built this and our journey and the road acquiring customers.
Want a trial, try https://socialreech.com/register/?trial=true and you should be good for 7 days without a CC
Have any questions feel free to contact us at @socialreech
Cheers