Okay, this is something I’ve been playing around with for a while now, trying to get a better understanding of, and I’m super pleased to finally be able to publish this.
As with most developers, I’ve worked with APIs for a big chunk of my career – being able to access third party data in a secure fashion to use in your own applications is kind of one of the cornerstones of being a good and efficient developer and I’ve utilised this heavily on projects like CLOCK and the work I did on the University of Lincoln Research Bridge. While I’ve always been happy to consume data from other parties endpoints, though, I’ve not often actually written my own; and while I have built my own solutions to allow applications to access data within the systems I’ve worked with it’s never been in a “proper” REST way.
One of the things I had hoped to do with Research Bridge, before the project itself was suspended several years back (that’s a story for another post… maybe…) was to convert the WordPress based proof of concept we’d built into something that was more sustainable and modern. While I orbited Laravel and Symfony for a while, one of the constant thoughts I had was to separate the back and front end into separate Node.JS apps – the back end to handle the data collection and distribution, and the front end to get this data and display it to the user.
As readers of this blog will know, I’ve been a tinkerer with Node.JS for a number of years and, to me, this seemed like the logical choice to not only simplify the code base, but also to make the core “bridge” data easily reusable by other applications. While I never got the opportunity to learn and apply this to the production Research Bridge app, it’s something that I’ve returned to over the last couple of weeks, toying with different tutorials and ideas to get to a point where I have what I’d consider a good foundation for building a RESTful endpoint to act as a backend for an application.
Now, I can’t fully take credit for the code – it’s largely influenced by this Medium article by Abhijit Roy, however I have made some tweaks such as simplifying down the schema so as not to make it too bulky for a starter project, as well as tweaking the code formatting to match my own. Still, if you want to get a better understanding of what the code is doing, check out that original article.
So, first things first, why MongoDB? Well, again, it was something I’d wanted to get to grips with for a while, being a SQL focussed developer for my entire career. As with many things, this revolved largely around the requirements of the roles I’ve been in. The idea of a database that stored its data not as structured SQL but effectively as collections (that’s what “tables” are literally called in MongoDB land) of JSON documents fascinated me.
One of the things that stood out for me when playing around with this, is that, while you’re learning at least, it’s far easier to set up your DB environment using the free service at MongoDB Atlas. While I got MongoDB up and running on my Mac no problem, it was quite the fiddly process – for experiments, Atlas will do exactly what you need to and host your data in the cloud.
Also, when you’re testing your endpoint with Postman (which is a fairly essential piece of kit, by the way), don’t forget to set the body type of your Post requests to Raw and JSON – I had a fantastic time trying to figure out why my perfectly correctly figured JSON data was being rejected by the insert function and this was the reason… 🤦♂️
Anyway, I hope this helps you if you’re interested in API development. It’s definitely something I’m hoping to be playing around with in the future and the next step is to create a tasty front end (I’m thinking of using React) to plug onto the API here.
As always, please shout up in the comments!