27
loading...
My Hacktoberfest journey with Appwrite
This is my third Hacktoberfest after completing the challenge in 2019 and 2020. I began programming in April of 2018 when I made the switch from an experimental biologist to a computational one. I remember the feeling of learning so much every day – "like drinking out of a firehose" was how I described it to my new graduate research advisor. I began with R, a common language in computational biology, but began picking up pieces of Python, too. Eventually, as I began to realize the power of being able to arbitrarily control computers, I began also dabbling in more diverse areas such as learning Swift to build macOS, iOS, and watchOS apps. As I learned one thing, I ran across ten more technologies that I wanted to use! Still, it took over a year for me to be truly comfortable with a programming language, where the syntax becomes second nature and the coding flows more fluidly. Every now and then, I look back to see how far I have come; this Hacktoberfest was a great opportunity for such reflection because I can compare one year to another.
Last year, my pull requests were on my own projects: two to for my Apple Watch telemetry recording app, one was for a workout Watch app, and the third was for the research project I was working on at the moment (this paper has since been published, "The origins and genetic interactions of KRAS mutations are allele- and tissue-specific" and the code is open source). This year, in order to enhance my learning, I challenged myself to contribute to others' projects. In my opinion, I have been quite successful with contributions to Fig, tldr, snakemake, and pymc3-examples. In addition, I have also taken up the challenge of learning about Appwrite, one of the sponsors of this year's Hacktoberfest, and producing educational content about the service. (With some encouragement by the offer of free stickers 🙃) I found this a great opportunity to learn about an essential world of programming that I had yet to deal with: backend services.
Appwrite is a free, open-source, and secure "Backend as a Service". It provides necessary functions such as user and account management, databases, file storage, etc. In addition, it is incredibly easy to get up and running with a local development server or a cloud server as the entire service runs on a collection of Docker containers. Appwrite has a natural ability to scale, making it easy for small and large apps.
Because my programming background is primarily for scientific purposes, I really had little experience with servers and backends. Until now, my only real experience was with my Coffee Counter web application that is hosted on Deta, a great service for beginners. This app (which is still running and I use everyday through a SwiftBar app in my Mac's menu bar) technically has a backend database, but it is relatively rudimentary and completely managed by Deta – a great option for getting started, but the constraints mean that I cannot get a deeper understanding of the technology. Thus, many of the features of Appwrite were completely novel to me.
I began by reading the documentation and various tutorials including the #30DaysOfAppwrite series. While it was definitely fun to take a deep dive into this new territory, the complexity was also intimidating. After I had read enough and was beginning to put the pieces together, I knew it was time to start trying my hand at using Appwrite.
One piece of the backend puzzle that I was really keen to learn about was deployment. I had many questions about the process, the complexity, how to use the final product once it is setup, security, etc. I decided, therefore, to begin with learning how to deploy an Appwrite server on the cloud and documented the process as a tutorial on my website.
I was a bit nervous at first as I imagined all of the things that could go wrong including racking up a sizable bill from the cloud provider to opening a security hole in my computer when connecting to the world wide web. (The first issue was assuaged by a promotional offering from DigitalOcean of $100.)
I played around with DigitalOcean, creating a new Droplet, destroying it, rebuilding a new one, and so on. As I played around on the servers and did some research when I came across parts of the process I wasn't familiar with, my confidence grew. In the end, I found that Appwrite had actually published a ready made Droplet on the DigitalOcean Marketplace, making setup (and, admittedly, my tutorial) much easier. Further, accompanied by the post "Appwrite for Production", the pre-configured security settings on the Marketplace offering were great for learning about the various pieces of a server that need to be locked down. I was also thrilled to see how simple Appwrite made this process, meaning that I could defer to people far more knowledgeable than I on these topics.
When all was said and done, I learned a lot about deploying a service to a cloud server and about how simple it was to accomplish with Appwrite. While I am still somewhat intimidated by the complexity, I am far more comfortable with the basics.
With a better understanding of deployment, I was content to begin experimenting with using Appwrite. I had some confidence that if I would build something worth using, I could actually send it off to the cloud for real use.
To get me feet wet, I made a demo app describing how to interact with an Appwrite-managed database in a Python application. As I have been considering upgrading my Coffee Counter application mentioned earlier, I thought it would be a good starting location for a theme for the app.
It took some playing around with simple code, but I eventually got the hang of making read and write requests through Appwrite's Python SDK. The GUI Console from Appwrite makes this trial-and-error process much easier than just blindly guessing at bugs. I could make a write request and actually see the results. Also, I could make a filtered query and ensure that all of the correct results were returned.
With an understanding of how to interact with the Appwrite database, I wrote up a few primary API endpoints using FastAPI then set to combining the two – a user makes a request to the FastAPI endpoints, the requests get processed into a database query, and the query gets made. I came up with a system of using pydantic as a layer between my web API and Appwrite's return type. I discuss this more in the README of the demo, but I was very happy with the usability and safety of using this validation layer to communicate between the two halves of the app.
In the end, this demo app was much easier to build than I had suspected, in part due to how much complexity Appwrite deals with on my behalf.
My ability to learn about and use a new technology as complex as Appwrite would have likely been to large a task last year. While I am far from an expert, the fact that I could demonstrate the ability to use it sufficiently for simple applications is quite thrilling. I think this is one of the main goals of Hacktoberfest and for this opportunity I am very grateful. Overall, this learning process itself gave me more confidence in handling this part of a project and I look forward to using these skills and knowledge in my future work.
27