Serverless Answers
October 21, 2020
To Begin With…
I’ve had a particular project in mind for some time now - ever since we tried to implement an open source Stack Overflow clone at work and had a number of issues, I’ve wanted to build an open source serverless SO clone. One may already exist - I haven’t searched extensively. It’s just something I want to try.
To start out, I’m not going to be bothered with adding all of the features that it will need in the long run, such as LDAP and other integrations. I just want to get it off the ground. And since it will be open source, perhaps I can get some help or advice on making such integrations modular. I’ll admit, my serverless and modular design experience is rather limited, and I’m not much of a UI/UX designer. Please don’t set your expectations too high.
Considerations
I have a few requirements for the project:
- It should be serverless. Naturally there are always servers involved, but I don’t want to have to manage them. In addition to reduced maintenance, serverless designs should be more cost-effective, especially in the early stages when there is little to no traffic to a particular instance of the application.
- It should be fairly cloud-agnostic. I don’t want to make it specifically an AWS project, though that is likely where I will be working for the most part. As such, I expect to use the serverless framework with implementations as vendor agnostic as possible. It may prove impossible to be completely agnostic, but I don’t want to get to too tied down to AWS Amplify or other very vendor-specific tools.
- It should be API driven. Perhaps obvious, but I don’t want to build the project around the UI, instead the UI should be a separate, perhaps even optional, component of the design. Though I plan to build an UI with React, it should also support Angular, Ember, or whatever framework or lack thereof a developer chooses.
REST or GraphQL?
I’ll be honest, I have very little experience using GraphQL, but that’s what we’ll be using for the project. I’ve worked with RESTful(ish) APIs for most of my career. However, for this project I believe it’s time I jump in and get some solid experience with GraphQL. Not just for experience sake, but because I feel it is the right tool for the job. Take your basic question list page for example - how many REST API calls do we need to pull question and tag info, vote counts, answer counts, view counts, author information… If we’re strict with REST, it will be a lot… for each question. And then we still deal with overfetching data and the like. So GraphQL it is.
That’s all for now
I’ll follow up with more details regard design and my thought process as I move forward. Don’t expect perfection - this is a learning experience for me, that I hope will be education for others as well.
Written by Clay Harris, a software engineer from Georgia. Follow me on Twitter