11

Useful Resources and Project Ideas

In the final chapter of this guide to building applications with FastAPI, React, and MongoDB, we will use the FARM stack components to briefly touch on or cover topics that are important, often crucial, but haven’t been discussed in the previous chapters, as well as reccomend some further further actions that you could partake if you want to deepen your understanding of the technologies that build up this interesting and flexible stack.

We will provide you with some guidelines when it comes to building data-driven or data-intensive applications, as well as some practical advice when working with the FARM stack and maybe some ideas for projects where the FARM stack (or very similar stacks) could fare pretty well. As a side note, I will add a couple of thoughts on learning and finding your way in the ever-growing and always-changing web development and analytics fields. This will be helpful for those who come from the most diverse backgrounds, but their jobs or maybe their newfound passion drives them to find a path through the data-driven world of the 21st century.

In this chapter, we will cover the following topics:

• MongoDB Considerations
• FastAPI and Python Considerations
• React Practices
• Other Topics
• Some project ideas to get started

MongoDB considerations

In Chapter 2, Setting Up the Document Store with MongoDB, we provided a concise introduction to MongoDB that should be enough to get you started with simpler projects. However, MongoDB is a complex ecosystem employed by enterprise-level companies, so diving deeper into its features and patterns will only benefit your developer’s abilities and understanding of the NoSQL paradigm.

One of the first steps in this direction is data modeling or schema design – and it is often said that your data model should reflect how your application will see the data and its flow, starting from the queries you will be making. There are advanced design patterns that apply to MongoDB schemas that are beyond the scope of this book.

Some of the more popular MongoDB document modeling suggestions were mentioned in Chapter 2, Setting Up the Document Store with MongoDB, but let’s add some more, formulated differently – they tend to sound a bit like Haiku poetry:

• Objects should be combined, in the same document, if they are meant to be used together
• When separating objects into different documents, try not to make JOINs necessary, although simple LEFT JOINS are possible through the Aggregation Framework
• The frequency of the data use cases should dictate the schemas – the most frequent data flows should be the easiest to access

Coming from the relational database world, modeling relationships often boils down to the choice between embedding and referencing. In our simple application of used cars, we opted to reference the user ID when we made the CRUD application with the users since it was the simplest thing to do, but that could probably apply to a real-world setting as well. There are numerous empirical rules, so to speak – if the many sides of a one-to-many relationship could contain hundreds of items, embedding is probably not the best way to go, and so on.

As one of the numerous and useful MongoDB guides provided by the Mongo Team itself states, in a semi-joking tone, embedding should be preferred in relationships that are one-to-one, one-to-few, and one-to-many, while referencing should be used in one-to-very-numerous-many and many-to-many cases (https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/).

As a side note, Python drivers such as PyMongo and its async sibling, Motor, play extremely nicely with MongoDB. Given Python’s rich data structure system and data processing capabilities, it is relatively easy to change and mix things up, change schemas on the fly, and try out different types of documents until you find the optimal (or suboptimal, but good enough) solution for your particular use case.

I want to finish this section by mentioning two interesting projects that could be included in some of your applications: Beanie (https://roman-right.github.io/beanie/) is an Asynchronous Python object-document mapper (ODM) for MongoDB based on Motor and Pydantic that can speed up the creation of CRUD applications. Another interesting project is Mongita (https://github.com/scottrogowski/mongita), which dubs itself as a SQLite for MongoDB. It could be particularly interesting as an embedded database for lighter cases in which you want the keep the data local, or for prototyping even before having to set up MongoDB or Atlas.

FastAPI and Python considerations

This book intentionally omits a brief Python tutorial and there are several reasons why this was a decision from the start. Apart from becoming ubiquitous and omnipresent, it Python encompasses data and text processing, web development, data science, machine learning, numerical computations, visualizations, and virtually every possible aspect of computing (it has even had a brief excursion into the browser’s world, the Kingdom of JavaScript). Python is a truly beautiful and peculiar language, built with a purpose and developed over the years into the modern versions (3.6+ at the time of writing) that we use now. Although its syntax and keywords are simple and the language has been written with clarity in mind, it takes some time to learn and then some practice to learn the Pythonic way of doing things. Being so popular as Python is, it has various benefits, so there are excellent Python books and courses that emphasize the proper use of Python’s rich data structures and the way it treats objects and functions, as well as the modern async paradigms that are often used in FastAPI and when interacting with MongoDB. So, dedicating it a mere chapter or two couldn’t do it justice, in my humble opinion.

What is considered good practice in Python is valid in FastAPI. However, because FastAPI itself translates simple Python functions (or even classes, inspired by Django’s class-based views) into REST API endpoints so seamlessly, you don’t have to do anything out of the ordinary. FastAPI is built in a way that favors you, the developer, giving you the necessary flexibility and smoothness that you may even forget that you’re writing an API.

Some fairly generic considerations that should be part of your FastAPI development process are as follows:

• Use Git and GitHub, learn a simple workflow, and stick to it. It is easier to learn one workflow and use it until you get used to it and then switch, rather than trying to learn all the commands at once, especially if you’re a one-man-band trying to automate or REST-ify a business process!
• Keep your environment variables in .env files, but also back them up somewhere (API keys, external services credentials, and so on).
• If you haven’t already, even if you’re a seasoned Python developer or you have maybe written just a text processing script or two, learn Python’s type hinting system. It is closely related to Pydantic and it adds a layer of robustness to your overall code. It is also an integral part of coding a FastAPI application.
• Structure your application properly. Although it is very easy and tempting to create even a feature-rich application in a single file, especially if you do not have a clear specification, resist this urge. The FastAPI documentation site has an excellent page on structuring larger applications and the internet already has some variations of it.

The main idea is to break the application into routers and Pydantic models so that they have separate directories (we had a /routers directory in the book, so we should have had a /models directory as well). These directories should each have an empty __init__.py, making them Python modules. I put external service utilities either in a separate file or in a /utils directory, but you could go granular, depending on the complexity of your app. Keep in mind that you will always end up with an ASGI application that is the only endpoint referenced by your server of choice, be it Uvicorn or something else.

Testing FastAPI applications

I have left out the most important topic that was not covered in this book for last – testing. Put simply, testing is necessary to ensure that our application behaves the way it was supposed to. Without delving into the theory of test-driven development (TDD) in which tests are written before the actual code, here, I will just point out some specific issues that you may run into when working with the async MongoDB driver (Motor) and FastAPI. Unit testing your API is essential and, to be honest, isn’t even difficult to set up –every endpoint should be tested, and they should perform the tasks that they are supposed to perform. While unit testing in Python already has several mature frameworks, such as unittest and pytest, some FastAPI-specific points are worth mentioning.

The FastAPI documentation recommends (at the time of writing) that you use the TestClient provided by Starlette. Francois Voron, in his excellent book published by Packt on FastAPI (Building Data Science Applications with FastAPI), recommends a slightly more advanced setup using HTTPX (an async HTTP library similar to Requests, developed by the Starlette team) and pytest-asyncio, making the whole process completely asynchronous.

The inclusion of Pydantic makes testing FastAPI applications a pleasant experience and it enforces certain practices that tend to produce more stable software. FastAPI’s automatic documentation, on the other hand, is an incredibly helpful tool (that we haven’t used much in this book, since I opted for REST clients) that saves you time and frequent trips between the code editor and the client.

React practices

In Chapter 1, Web Development and the FARM Stack, we chose React for our frontend because of its apparent simplicity and flexibility. Don't be fooled by this apparent simplicity - writing serious React applications is a complex endeavor! React is constantly at the top of the most used, loved, and popular frontend technologies, so there is a plethora of React resources, books, courses, and tutorials covering every facet of the library (if you are a visual learner, try the video course by Academind GMBH and its main author, the eloquent and humorous Maximilian Schwarzmüller – React – The Complete Guide).

We haven’t even scratched the surface of what is possible and what it means to begin developing performant and maintainable React apps. Solid knowledge of JavaScript and ES6 is the best foundation for becoming a better React developer, but it is also important to dive a bit deeper into some fundamental React concepts and explore the Hooks mechanism, the components life cycle, and the components hierarchy. Familiarize yourself with other hooks – in this book, we just glimpsed over two or three of the most popular, but there are many more, and knowing how they work and especially why they work the way they do will make you a better React developer.

As of 2022, React functional components (the only ones that we have seen in this book) are generally preferred to older class-based ones as they are more concise, maintainable, and generally flexible. This would also be my personal preference.

Other topics

In this section, we will further emphasize some other important points that might work in our favor when using the FARM stack. While technically there is no barrier, you should be able to use the FARM stack for virtually any type of web application that you can think of – as any tool, the stack might be more suitable for some types of apps and less for others.

Authentication and authorization

An entire chapter in this book is dedicated to implementing a possible JWT-based authentication solution with FastAPI and its consequent application in React. Yet, as mentioned in that chapter, that might not be the best or even a viable solution – you may need to revert to a third-party provider such as Firebase, Auth0, or Cognito. Before committing to a third-party solution, be sure to fully understand the pros and cons and the consequences of a potential lock-in, especially if you are planning to scale the application!

Data visualization and the FARM stack

We have built a couple of rather simple visualizations, but you can already imagine that with properly formatted and granular JSON responses and React as the frontend, almost anything is achievable. This possibility to practically mold the data in the way that you might need it for a particular visualization opens, in my opinion, a great playground where you can test, tinker, and try out different solutions, maybe through iterations, until you reach the type of data visualization that you are satisfied with.

There is a broad spectrum of visualization requirements and there is probably no need to try and craft a Shirley Wu D3.js piece of art where a simple two-color stacked run-of-the-mill bar chart could have done the job. However, with the availability of a fast backend and MongoDB accommodating virtually any type of data structure that you might throw at it, you are ready for any task. D3’s Observable wrapper has a very interesting interface and abstracts much of D3.js mechanisms, so it might be a good place to start. Displaying high-res static charts may also be a very good option.

Relational databases

If your business problem needs the complexity of relational databases and their strict structure, querying with SQL and other features that only a relational database can provide doesn’t mean that you have to ditch the FARM stack altogether! Given the modularity of FastAPI and using some of the deployment options that we explored throughout this book, nothing is stopping you from plugging in a relational database (Postgres, MySQL, and so on), exploring the documentation of SQLAlchemy or some async database Python drivers, and simply adding said functionality while managing the users, for instance, through MongoDB.

Some project ideas to get started

To end this book on a creative note, we will suggest some project ideas if you are willing to dive deeper into the possibilities of the FARM stack and hone your skills, but above all, unleash your creativity.

Old School Portfolio website

This is a weird little project just to show off that FastAPI, React, and MongoDB are perfectly capable of handling simple portfolio sites – an about page, service, gallery, contact form – the usual stuff. Create a nice design (or steal one that you like and try to recreate it in Tailwind CSS!), plug in React-Router or Next.js if you want to make it fast, and make use of server-side generation and image optimization. For the content, define a couple of Pydantic models: a blog post, portfolio item, article – whatever fits your needs – and then create simple routes for serving them via GET requests. Since this is a hardcore developers blog, you don’t even need to create an authentication system and POST or PUT routes: text-related content will be entered directly into MongoDB (Atlas or Compass) and images will go to separate folders on Cloudinary, queried directly through the API. Of course, this is a bit of a joke, but it would be great practice, nevertheless. Try incorporating markdown – a powerful text pre-processor that converts simple text (markdown) into valid HTML. Both Python and ES6/React have excellent libraries for handling markdown, so try to find a good combination.

React Admin Inventory

The idea is to try and create an inventory system built on top of React-Admin (https://marmelab.com/react-admin/), with authentication from Auth0 or Firebase, and a public-facing interface. React-Admin provides an admin interface similar to the one used by Django and it is based on CRUD verbs: each resource (or item) that exposes interfaces for POST, PUT, GET, and DELETE operations can be edited, deleted, and read and new instances can be created. Explore the package and try to think of some type of collection that you may want to manage. Bear in mind that there are excellent tools such as Airtable (an online spreadsheet-like application) that expose REST APIs that can be called from your FastAPI routes!

Plotly-Dash or Streamlit – like exploratory data analysis application

Pick a dataset that you are familiar with – when I was starting to play with data, I always felt most confident with basketball-related data from the NBA: it is easy to spot correlations and outliers with the bare eye when you know where the data comes from and how it was generated. For instance, it’s rare to find a player that shoots like Steph Curry but dunks like Russell Westbrook. Try creating an input pipeline that programmatically accepts data (and test it out thoroughly!) – be it from a little web or, better, API scraper or from an input file that uploads a JSON or CSV file. Clean the data, preprocess it, and insert it into the MongoDB datastore. From there, and based on the structure of the data at hand, try to figure out some useful filters and controls, not unlike enterprise tools such as Tableau or Google Data Studio – if you’re already familiar with data like that, you will know what to expect. The only difference here is that you are free as a bird and you can build your way up while exploring, coding, and having fun. To return to my NBA players example, you could prepare MongoDB queries that separate players by position, team, age, and years of experience as a first stage. After that, you can fire up a Jupyter notebook, install a couple of visualization libraries (I like Plotly!), and see what types of correlations or groupings can come up. After you have found some interesting pandas-driven data wranglings, you can just extract them into separate functionalities, test them out a bit, and then incorporate them into FastAPI endpoints, ready to be visualized with D3.js or Chart.js. Finally, you could deploy your application and share it with your friend that manages your fantasy team to show him the data backing your draft decisions. We have seen how easy it is to embed a machine learning model built with Scikit-Learn, so give it a go: try embedding a neural network model, if that’s your thing, with Keras or try out some simple linear regression!

Previous knowledge of data visualization and exploration frameworks such as Streamlit or Dash will help you.

A document automation pipeline

I don’t know about you, but I have always been surrounded by repetitive documents that have the same structure – be they Word documents with a branded header and footer and three colors and five font sizes, or Excel reports with the same column headers and colors and maybe even some (Excel) charts inside of them. Try to think of a document server based on the docx-tpl package, which allows you to define a Word template, formatted as it should be, and then pass a context containing all the data that needs to be in the document – text, images, tables, paragraphs, and titles – all while maintaining the initially defined styles. Similar and even more powerful automation can be achieved with Excel – using pandas for complex calculations, pivoting, and merging different documents into one. After creating the templates, try to think of some FastAPI endpoints that would perform POST requests and save the posted data to a MongoDB database, along with the data (for instance, the title of the document, the author, the data, and so on), and then trigger a DOCX or XLSX document render. Save the file with a recognizable name (maybe by adding the current time or the UUID library, for uniqueness) in a directory and ensure this directory is servable, either by FastAPI directly (via the static files functionality) or, in case you plan to have a significant number of heavy documents, maybe even an entire Nginx server block – after all, this is what Nginx excels at (pun intended). These files could then be accessible to all the team members or even sent directly via mail with a CRON job or something similar. Seemingly silly projects like this often result in incredible work time reductions in the long run.

Summary

In this brief chapter, we added some pointers for further development and fortifying your FARM stack knowledge and experience, as well as some project ideas that you should customize and use as a starting point for your very own projects.

It has been quite a ride! We have made the case for a new and modern stack – the FARM stack – and we have introduced the protagonists.

You have learned how to perform simple and not-so-simple operations with MongoDB and create, read, query, and aggregate data that will later be converted into endpoints for your applications. You should also be comfortable setting up a MongoDB document store in the cloud or locally and wrangling data through the shell, the Compass GUI, or code.

We introduced FastAPI – probably our first billed actor in this web development action movie – a simple, clean, and fast Python framework that allows us to bridge the gap between our ideas and our code in an elegant, fast, and developer-friendly way, using the experience of the most successful Python web solutions from the past and the present.

You are now able to create user interfaces that match the workflow of your application and, more importantly, your data flow. Even though we barely explored the very basics of React, you should be able to take it from here and dive deeper and deeper into concepts such as state management – local and global, custom hooks, component life cycles, and much more.

We have created numerous simple or mildly complex applications to showcase the capabilities and the flexibility of the stack, but also as a way of helping you get started quickly – we explored server-side rendering and image optimization with Next.js, sent emails, manipulated images, and performed data visualizations as a part of what can easily be achieved with the FARM stack.

Finally, we deployed our web applications through a myriad of free or very cheap services, since I strongly believe that without that last step, the development process, especially while learning new concepts, isn’t as gratifying as it could and should be.

I believe that the FARM stack has a bright future as a stack of choice for professional development teams and data wranglers or freelancers who just need to tell a story through a web application. I hope you have enjoyed this journey as much as I have, and I look forward to you building some FARM stack apps!