At JetBridge we enjoy developing software applications with our clients that we can take pride in while expanding our areas of knowledge and expertise at the same time. Because we are frequently starting on new projects we have standardized on a harmonious and expressive set of tools and libraries and frameworks to help us rapidly lift off new applications and deliver as much value as we can with minimal repetition.
Our setup isn't perfect or the end-all stack for every project, but it's something we've evolved over years and it works quite well for us. We continue to learn about new tools and techniques and evolve our workflow so consider this more of a snapshot in time. If you aren't reading this in July of 2019 then we have probably modified at least some parts of the stack.
Methodology
Our theory of software development is: don't overcomplicate things.
Pragmatism and business value are the overriding concerns, not the latest and coolest and hippest frameworks or tech. We love playing with new cool stuff as much as any geek but we don't believe in using something new just for the sake of being new or feeling unhip. Maturity and support should factor into deciding on a library or framework to base your application on, as should maintainability, community, available documentation and support, and of course what actual value it brings for us and our clients.
There is a tendency a lot of engineers have to make software more complex than it needs to be. To use non-standard tools when widely available and known tools exist that might already do the job. To try to shoehorn some neat piece of tech someone read about on Hacker News into something it isn't really suited for. To depend on extra external services when there are already existing services that can be extended to perform the desired task. Using something too low-level when more abstraction would really simplify things, or using something too fancy and complicated when a simple system-level tool or language would accomplish things more expediently.
Simplicity is a strategy that when used wisely can greatly increase your code readability and maintainability, as well as result in easy to manage operational environments.
Frontend
By the time I am writing this all frameworks and libraries we use have likely been superseded by cool new hip JS jams and you will sneer at our unfashionable choices. Nevertheless, this is what is working well for us today:
- React: Vue may have more stars on GitHub but React is still the industry standard and is used and supported actively by Facebook among others. Writing apps with React hooks really feels like we are getting closer and closer to functional programming, adding a new level of composibility and code reuse that was clumsily achieved with HOCs before.
- Material-UI for React is a toolkit that has almost every sort of widget and utility you might need, powerful theming and styling options, integrates CSS-in-JS very smoothly and looks solid out of the box. It is essentially an implementation of the UI paradigms promulgated by Google so working within its constraints and visual language gives you a good foundation.
- Create-React-App/react-scripts: This really does everything you need and configures your new React app with sane defaults. You never need to monkey around with Webpack or HMR again. We have extended CRA/r-s to spit out new frontend projects with extra ESlint and prettier options and Storybook.
- Storybook: We prefer to build a component library of small and larger components implemented in isolation using mock data, rather than always coding and testing the layout and design inside the complete app. This allows UI devs to work without being blocked on completion of backend endpoints, helps to enforce the concept of reusable and self-contained components, and lets us preview the various interface states easily.
-
TypeScript: Everyone uses TypeScript now because it's good and you should too. It does take some getting used to and learning how to use it properly with React and Redux requires some small amount of learning, but it's entirely worth it. Remember: you should never need to use
any. And when you think you need to useany- you probably just need to add a type argument (generic). -
ESLint: ESlint works great with TypeScript now! Don't forget to set
extends: ['plugin:@typescript-eslint/recommended', 'plugin:react/recommended', 'react-app'] - Prettier: Set up your editor to run Prettier on your code when you hit save. Not only does it enforce a consistent style, but it also means you can be way way lazier about formatting your code. Less typing but better formatting.
- Redux: Redux is nice... I guess. You do need some central place to store your user authentication info and stuff like that, and redux-persist is super handy. In the spirit of keeping things simple though, really ask yourself if you need redux for what you're doing. Maybe you do, or maybe you can just use a hook or state instead. Sure maybe you think at first that you want to cache some API response in redux, but if you start adding server-side filtering or search or sorting, then it really is better off just as a simple API request inside your component.
- Async/await: Stop using the Promise API! Catch exceptions in your UI components where you can actually present an error to the user rather than in your API layer.
- Axios: The HTTP client of choice. We use JWT for authentication and recommend our axios-jwt interceptor module for taking care of token storage, authorization headers, and refresh.
I don't believe there's anything crazy or unusual here and that's sort of the point. Stick with what's standard unless you have a good reason not to.
Backend
Our backend services are always designed around the 12-factor app principles and always built to be cloud-native and when appropriate, serverless.
Most projects involve setting up your typical REST API, talking to other services, and performing CRUD on a PostgreSQL DB. Our go-to stack is:
- Python 3.7. Python is clean, readable, has an impressively massive repository of community modules on PyPI, active core development, and a pretty good balance of high-level dynamic features without getting too obtuse or distracting.
- Type annotations and type linting with
mypy. Python does have type annotations, but they are very limited, not well integrated, and not usually very useful for catching mistakes. I hope the situation improves because many errors have to be discovered at runtime in Python when compared with languages like TypeScript or Go. This is the biggest drawback to Python in my opinion, but we do our best withmypy. - Flask, a lightweight web application framework. Flask is very nicely suited to building REST APIs, providing just enough structure to your application for handling WSGI, configuration, database connections, reusable API handlers, tracing/debugging (with AWS X-Ray), logging, exception handling, authentication, and flexible URL routing. We don't lean on Flask for much besides providing the glue to hold everything together in a coherent application without imposing too much overhead or boilerplate.
-
SQLAlchemy for declarative ORM. Has nice features for handling Postgres dialect features such as
UPSERTandJSONB. Ability to compose mixins for model and query classes is very powerful and something we are using more and more for features like soft deletion. Polymorphic subtypes are one of the most interesting SQLAlchemy features, allowing you to define a type discriminator column and instantiate appropriate model subclasses based on its value. - Testing: subtransactions wrapping each test, pytest-factoryboy for generating fixtures from our model classes for pytest and for generating mock data for development environments. CircleCI. Pytest fixtures. Flask test client.
- Flask-REST-API with Marshmallow helps succinctly define REST endpoints and serialization and validation with a minimum of boilerplate, making heavy use of decorators for a declarative feel when appropriate. As a bonus it also generates OpenAPI spec documents and comes with Swagger-UI to automatically provide documentation of every API endpoint and its arguments and response shapes without any extra effort required.
- We are currently developing Flask-CRUD to further reduce boilerplate in the common cases for CRUD APIs and mandating strict data model access control checks.
In projects that require it we can use Heroku or just EC2 for hosting but all of our recent projects have been straightforward enough to build as serverless applications. You can read about our setup and the benefits this brings us in more detail in this article.
We have built a starter kit that ties together all of our backend pieces together in a powerful template to bootstrap new serverless Flask projects called sls-flask. If you're thinking of building a database-backed REST API in Python, give it a try! You get a lot of power and flexibility in a small bundle. There isn't anything particularly special or exotic included in it, but we believe the foundation it provides adds up to an extremely streamlined and modern development toolkit.
All of our tooling and templates are open source, and we often contribute bug reports and fixes upstream to modules that we make use of. We encourage you to try out our stack or let us know what you're using if you're happy with what you're doing. Share and enjoy!
Top comments (12)
Very interesting post. Regarding picking Python for the backend and since you mention the lack of good type annotations as a big disadvantage (I agree), did you consider picking another language?
NOTE: this is NOT a criticism to the choice of choosing Python or to Python itself, which I really like btw. I just agree with your statement "This is the biggest drawback to Python in my opinion" and I find it interesting to see if that made you consider other languages, and if so, which ones were on your radar.
ps - I am totally onboard with the Boring stack, so much that I actually use the same definition when picking a new tool for a commercial project.
We've been trying to make use of Python type annotations and Mypy but it is pretty underwhelming. We are in all likelihood going to start using Go for some new projects mostly because of the wonderful strictness at compile time.
Yes, that's really hard to cope with the fact that types are an afterthought in some domains. Especially when the library ecosystem is not on the same page.
Solid stack! I share 90% of it.
And since you are already using
eslint, don't forget to add a linter for your Python project as well!I recommend to use wemake-python-styleguide. It is the strictest Python linter out there. It will help you to find possible errors in your code early, show you possible refactoring opportunities, and enforce consistency across the project's codebase.
Check it out:
The strictest and most opinionated python linter ever!
wemake-python-styleguide
Welcome to the strictest and most opinionated python linter ever.
wemake-python-styleguideis actually a flake8 plugin with some other plugins as dependencies.Quickstart
You will also need to create a
setup.cfgfile with the configuration.We highly recommend to also use:
Running
This app is still just good old
flake8And it won't change your existing workflow.See "Usage" section in the docs for examples and integrations.
We also support Github Actions as first class-citizens Try it out!
What we are about
The ultimate goal of this project is to make all people write exactly the same
pythoncode.Awesome post :) It's quite unusual to have a python backend for web development. May I know how do you train and hire developers onboard your team.
I do not think it is at all unusual - Flask and Django are extremely popular projects.
Doing the Flask and SQLAlchemy tutorials is mostly enough to get anyone up to speed. There isn't a lot of voodoo or crazy complicated things going on.
great post I love the frontend part!!
Great post! Looking to do the same with my projects. Too often I'm between stacks when I really need to build the project!
Thanks for the discussion, I think the "boring" stack (aka yesterday's exciting stack) is often a good place to be. A team is powerful when they have an evolving yet standardized approach.
This is a very interesting read, thanks for sharing. I'm in a situation where I need to define a software development stack for a new team, and this gave me really good options to consider.
Nice read 🙂
Thank you for sharing.
Python for backend is an interesting choice. Why not go with Node as a default choice?
No particular reason. Maybe when you can use MJS in node without experimental flags it will be getting close to ready for production.