Sprint #1 - Daily Scrum #05

Product: CMS API
Sprint Summary

Daily Objectives

1. Write up final sprint report
2. Draw out infrastructure diagram
3. Figure out automated deployment/installing tools
4. FIgure out how to use Bookshelf as ORM and what database models
5. Figure out node_modules(?) required
6. Figure out requirements and patterns for Rest API and GraphQL (also maybe json only)

Notes

Last day of the sprint! (haha jk -neil from the future but probably not the future you’re reading this from)

What to do:

1. Create test node + express application

I think I should be thinking of everything in terms of node-modules
Use Express.js to create ‘app’ objects So far express is just handling all the routes and passing them into controllers

So I want to figure out what kind of architecture I need first and then figure out how it’s actually done using Node.js.

MICROSERVICE:

1. Principles:
   • Single Purpose: each service should focus on single purpose and do it well
   • Loose Coupling: services should know little about each other; communication between services should happen through public interfaces
   • High Cohesion: each service encapsulates all related behaviors and data together; changes for new features should be localized to one service
2. What do I need to think about it I this project fits a microservice architecture
   • What would the microservices be?
3. Other Notes:
   • Monolithic persistent storage is potentially harmful, especially when making changes to the data structure while multiple decoupled architectures are dependent on it
   • Make sure to decouple ‘running services’ with ‘building services’
   • What exactly does service management and running services mean? Related topics include Networking, Communication Protocols and Deployment
   • For logging and observability, Medium creates a ‘DataDog’ dashboard for each service
   • https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f very useful and informative smile

SO, I’m going to create this as a microservices architecture! Why?

1. Good learning experience smile
2. This should be an ‘open-source’ project, so it’ll be easier for others to come in and make changes

What are things I need to define right now?

1. Services:
   • CMS hosting
   • Web hosting
2. To be continued…

Let’s figure a bit more about the backend? For now I’ll be using bookshelf, since creating a custom ORM solution will definitely take some time. I’m still confused on how exactly the backend ties into having a RESTful API or GraphQL service, so I need to look into that.

RESTful API:

• Representational state transfer; architectural style for distributed hypermedia systems
• Client-Server, Stateless, Cacheable, Uniform Interface, Layered System, Code on Demand
• Define Resource and Resource Methods
• For layering concepts, should it be:
  • Database → ORM → RESTful API Interface
• From the looks of things so far, the API has nothing to do with the database, all it does is deliver and help manipulate resources. An interface to interact with ‘Data Structures’ that are made and don’t exactly correlate with the literal database. As long as the API has access to the ORM I think things should be fine. However, I still need to differentiate the different roles of the ORM and the RESTful API.
• Designing the RESTful API
  • For the most part I just need to define what the actual RESOURCES and the RESOURCE methods the USERS or CLIENTS will need/want to interact with.

GraphQL:

• First, what’s the difference between a GraphQL API and a GraphQL Server? Or a GraphQL API Server? Or are they all the same thing?
• GraphQL is a query language for API’s, allows clients to get ask and receive for exactly only the data they need
• Organized in terms of types and fields, rather than endpoints. Helps avoid manual parsing code
• So I think I’ve confirmed you don’t need any specific database types or optimizations to create a GraphQL API. resolvers for the GraphQL API are responsible for fetching the actual database from a database, api, 3rd party service or whatever.
• Prisma is a tool used to ‘replace traditional ORMs’, which means its used to interact with the actual database. (Basically the ORM layer)

We might want to use a monolithic data structure with multiple services, since this project is hinged around everything accessing the content since it’s literally a CONTENT MANAGEMENT SERVICE omega

LMAO DO I INCLUDE A BUSINESS LOGIC LAYER? YEE LET’S GO FOR IT
What IS business logic first? Business Logic is the logic you’re writing to your program to handle the business rules you’re given. Example of business rules are when you’re transferring money, you need to ensure:

• The person has the authority to do so
• The transfer must be ATOMIC
• The transfer must abide by reporting requirements in compliance with the government

What kind of business logic could I even include here? A plugin for handling client payments? Can I track how much traffic any API’s or Projects are getting? Where would this happen. I’d need another layer between the ORM and the API’s to handle the business logic. And use the Admin panel to view and track the traffic as well as handle the permissions connected to payments for client users. Lmao that sounds a bit wild.

ETL pipeline stands for ‘Extract, Transfer, Load’
RPC stands for ‘Remote procedure call’ (example: gRPC, or Rest+JSON over HTTP)

Objectives Completed

• investigated different software architectures and decided to base the project on microservices

• researched more information on designing and creating RESTful and GraphQL API’s

Thoughts/Questions to Come Back To

• What is RAML? RESTful API Modeling Language
  • Language used for defining RESTful API’s and using it to automatically translate into any other programming language
  • I’ll look into this in a bit when I start designing the actual API. The main issue I’m worried about is how I’d make ‘dynamic’ schemas and endpoints as well as content without concrete types (posts with several H1 types, paragraph types, media etc. I’ll probably make some sort of linked list for this.)
• Maybe attach another microservice for actual web hosting

Plans for Tomorrow

• hey