BackCOVID-Q: Technology Overview
A Secure, Easy-to-manage Queue System for Drive-up COVID-19 Testing
This is part two of our COVID-Q overview. COVID-Q is an app we built to help manage a queue system for drive-up testing for COVID-19. If you’re interested in why we built the solution, see part 1.
The Technology
As an agency, we often spike out technical solutions with internal projects to prove them out before recommending on client projects. This project was an opportunity to put a few things through the paces and evaluate them for future use with our clients.
For this project, we used some of our favorites along with some new tools.
Some of our favorites include:
- Next.js for the landing page and the application. The landing page is fully static and leverages Next.js API Routes to process the contact form. The app is a mix of static and dynamic content.
- Chakra UIfor styling and base components. We’ve leveraged Chakra on quite a few projects now, and it has increased our speed and productivity developing responsive UI components and pages.
- Hosting on Zeit Now. Now comes with numerous benefits out of the box including deploy URLs for Pull Requests, a global CDN, and a Serverless architecture.
Tools we are Evaluating
A CMS and basic admin area provided by Sanity.io. The site re-deploys to Now via a webhook when editors publish content. We also like DatoCMS but Sanity is a bit more configurable and flexible. Sanity can also be self-hosted, and this was a good opportunity to put it through the paces.
We were less than impressed with Prisma 1. In fact, it caused a lot of issues on the project we used it on. That said, Prisma 2 is much more focused and has proven really promising. We encountered a few small issues with migrations, but the overall setup works well. We will continue to evaluate Prisma 2.
We use Apollo Server on most client applications. We tested out Urql on this project but did not find any benefits over Apollo. We likely won’t use it in the future. For simple GraphQL calls in scripts or times where a full-fledged client provides little benefit, we prefer graphql-request.
Now deploy buttons allow for a one-click clone from GitHub and instant deployment. We are using this to help spin up new COVID-Q sites for interested companies quickly.
Technical Questions and Answers
Why use both a CMS and a database on this project? Couldn’t you just store all of the content in the CMS?
We absolutely could. We chose not to do this for two reasons. First, using a separate database helps us with better HIPAA compliance should we need it. Storing patient data within a CMS like Sanity is less secure since we don’t have control over how the data is accessed. We’re not actually storing any Patient Health Information (PHI) in this app, but we wanted the flexibility should we need to start doing so in the future.
To keep the admin section of the site easy to use, we call our main API to fetch data for things like appointments and tokens.
Isn’t GraphQL overkill for this type of project?
GraphQL is definitely not necessary for the size of the API we’re working with. We decided to keep everything in GraphQL for a few reasons:
- It allowed us to test out GraphQL Nexus, which we’ve been meaning to evaluate.
- The CMS API and Prisma API were already GraphQL, so we wanted to avoid introducing another way of fetching data to the application.
Why use a Serverless infrastructure?
First, it keeps costs low. Second, the infrastructure will automatically scale to meet demand should it need to. Because we were providing a service to others, we wanted it to be maintenance-free.
The most important part of this app is certainly not the technology behind it. That said, we hope to help other development teams by sharing our insights as we’re evaluating new technologies for internal projects and client apps.
