In this chapter we are going to talk about what it takes to write a solid back-end and how we solve common issues in a very elegant manner.
We are not going to work on how to structure the front-end part. We are going to address topics such as: how do we structure the code, how do we test it, how do we lint it, and all sorts of elements that make an app great behind the scenes and simply a joy to work with.
We at Cult of Coders believe in the future of Meteor, making things easy for development is the key of success. But even if you have a powerful tool like Meteor in your hands, you can still make many mistakes and spend time learning from them. We made these mistakes so you don’t have to.
So why are we sharing them for free? When we could easily create a book and make some good bucks? Because money is not our objective. A thriving community is more valuable to us.
The main reason is that we love and support the community, the next is by engaging the community in this, we are able to gain more insights and to improve our knowledge.
That being said, we hope you enjoy this chapter and that it will open your mind.
May the code be with you.
We will begin with a story, a young developer joining a team of Meteor developers, and he receives his first task:
As a user, I want to create a post.
After creation, I want to send an email to the admin so he can approve it.
After approval, find the users that are interested in this post by their interests, and notify them.
From the client I would craft a form, and do something like a method call, but since our focus is backend, we won’t get too much on the frontend side of things.
In the server you start coding:
This looks like a simple way of doing things, the code is relatively clean, and it does its job.
But, then the Bigshot Code Reviewer comes to you and says the following:
- You need to make sure the user is logged in when creating a post
- What prevents the user of setting
isApproved: truein the post object? Never trust the client!
- What if I want to change
email@example.com one place.
- Post approval is not secured, you need an Admin role to do that
- What if the
/posts/:_idroute changes I want to be able to change it from one place
- What if I have multiple admins and want to notify them all ?
- The tags need to be validated as well, we don’t allow all possible tags
Because you are a good developer you listen to all of his requests and you start coding, then it will look something like this:
By this time your code has grown a lot, and you send it for review being optimistic… but our Bigshot Code Reviewer comes with a new set of requests:
- I need to be able to validate these tags at User level as well
- I want to have Emails centralized somewhere so I can have a nice layout
- When you find users you fetch a lot of data you don’t need!
So what’s the problem here? You want to do your job, and receiving so many comments makes you feel like you don’t know jack. Then, after you implement them you realize that your code grows and grows and if another developer wants to read your methods he will have a hard time because it’s simply too much. What if later on you want to send some Push Notifications, or other stuff, a method can grow to 200 lines? Unacceptable.
Let’s begin first with our Emailing service:
We already decouple mail sending in a nice manner, and we aren’t fetching from database things we don’t need. Nice!
Ok, nice, now as you can see the code can be read as poetry. By decoupling functions you understand what they do without seeing the code, this brings verbosity and makes the code a pleasure to work with. So, how will our methods look after these changes?
Wow! So clean and so sexy! Much more readable. But are we there yet? Is this how the code should look? Not by far.
But we made some good progress already, good job! We understood that separation of logic, makes the code manageable, easy to understand, and easier to test.
So why do we say not by far ?
Well, the Bigshot will still see some problems:
- If I want to write a test for PostService but not send emails how would I do that ?
- Tags need to be centralized somewhere and apply same validation when User updates interests.
- What if the user adds some extra fields to post object ? How do I stop that ?
- What if that absolute path for seeing posts needs also to be decoupled and used somewhere ?
- Emails still don’t have a nice re-usable layout
- PostService should be about Posts, not about notifying others, it has too much logic.
Ok, how do we close this Bigshot‘s mouth? We continue learning the principles behind quality code.
Please don’t treat it as just another link, you must absorb the teachings there, and make sure that until you master them, you read them daily or at least weekly for 2 months.
Even I read it from time to time, to refresh my memory.
After all this time? Always.