separate concerns (e.g. ORMs) - Helps devs focus on core functionality - You’ll write some yourself if need be Frameworks - Essentially needed for their ‘out of the box API’ features - For languages that usually have heavy frameworks, it’s best to find a micro version
an autodoc builder or generator /** * @method: properDocs * @param {intelligence} commonSense It only makes sense to document properly * @param {awesomeness} goodDev Good devs document their codes * @return {awesomeness} goodCode - It’s impossible to go wrong with a * properly documented code base. Moreso, * new devs can catch up easily. **/ properDocs: (commonSense, goodDev) => { }
files according to responsibility Services - should contain business logic and straightforward functional tasks related to an entity. - should abstract data manipulation and retrieval but should not directly implement the data store. If a library isn’t being used, then create repositories for that
files according to responsibility Models - should do exactly what the name suggests: model entities and represent them as entities with interfaces that can be used by the services - is sometimes simplified by an ORM module/library (e.g. bookshelf.js) or your repositories if no library is used
files according to responsibility Controllers - should always be the entry point - should simply co-ordinate a sequence of activities to be done by the services and decide what point to return an API response
files according to responsibility - Repository: function fetchUserById(userId) { Return mysql.select(‘*’) .from(‘users’) .where({user_id: userId}); } Function fetchUserAddressByUserId(userId) { Return mysql.select(‘*’) .from(‘addresses’) .where({user_id: userId}); } See how easy it’ll be to switch the data store technology if the need arises?
a helper file for constants where necessary - You want to do this: - Function getSomeData(page, limit) { let constants = require(‘app/lib/constants’); limit = min(limit, constants.pagination.MAX_ALLOWED_LIMIT); let opts = { page: page, offset: (page - 1) * limit, limit: limit } . . . } - Rather than this: limit = min(limit, 50);
to extend Use linting tools to ensure code quality Write unit and regression tests Protect your API (validate as much as you can) Dockerize your service
remain micro Must be 100% responsible for it’s data Must not be dependent on another service Should preferably not be responsible for caching Must not have any unrelated models hanging around
run in isolation - Fixed amount of CPU and memory - Easy deployments Cons: - Inefficient resource utilisation - Expensive - Slow deployment for new versions - Heavy lifting overhead
run in isolation - Fixed amount of CPU and memory - Encapsulates tech used to implement - Easy deployments Cons: - Not as mature as VMs - Not as secure as VMs - Heavy lifting overhead - Provisioning costs
Lambda - Package your service as a zip file and upload - Supply a metadata (and functions that handle ‘events’) - Automatically runs enough instances to handle requests - Services must be stateless - Limited to only a few languages
forloop
bkuhlmann
ivargrimstad
pangmoo
suu_mire0726
jaguar_imo
demuyan
aethiopicuschan
coconala_engineer
mraible
slephy2784
oskmr
holman
orderedlist
sstephenson
notwaldorf
zenorocha
eileencodes
bkeepers
tanoku
mthomps
myddelton
kneath
schacon
