5 ms·
Honestly, I'd pick what you know today and go with it. Node.js is a good way to go and has served me really well on a number of projects/fronts. However, Pyth
by davismwfl 11y ago
Honestly, I'd pick what you know today and go with it.
Node.js is a good way to go and has served me really well on a number of projects/fronts. However, Python is totally viable as well. Where node.js will not serve you well is if your api is blocking in nature. For those cases when we have a blocking call, we will send that call off to a queue and let a worker node pick it up and deal with it, saving our API from having anything blocking.
- cameronphillips 11y agoDo you have any preference for Django versus Flask for RESTful development? Our team mostly has Python experience (the rest of the backend is in Python) however we are not familiar with web API development and are worrying if a python-based API will have trouble down the line in terms of scalability/availability. If we could stick with Python as opposed to learning Node.js that would be the most ideal I think
- jstoiko 11y agoHey cameron, you can build APIs in minutes using Ramses http://ramses.tech http://ramses.tech, it's python. It takes a RAML file and spits out a production-ready API. It supports Postgres, Mongo and Elasticsearch our-of-the-box. AMA, I'm a core dev, and happy to help.
- davismwfl 11y agoGiven that Python is a core team strength I'd stick with it. Building a RESTful api is not that difficult if you stick with known patterns. As for which framework to use, I am not versed well enough right now in either Django or Flask to render an opinion. My guess is both frameworks have tradeoffs so you might stand up two sample production ready endpoints to see what those tradeoffs are, or spend time researching and asking people specific questions around the benefits/pitfalls. As for scalability/availability, Python can be just as scalable and available as node.js in my opinion, but you have to take some different routes to get there. The best recommendation I have is keep it simple and clean with each endpoint doing only one thing. I am anal about making sure any API endpoint I develop is very short and to the point, and does only 1 thing. For example, I don't like having a POST endpoint that saves three different records to a database, that should be three separate calls or a queued message to be processed by worker processes. This type of design makes your api far easier to maintain. The drawback of course is multiple calls and potentially more endpoints. But another benefit of designing it this way is that I can scale certain API endpoints individually and only add the complexity of scale where needed. In some cases too you can have an endpoint that implements some chain of responsibility to handle multiple calls and may be blocking, but this would be layered on your individual endpoints.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]