I came across this whitepaper on testing micro services. I clicked on this link because I am writing microservices now but I am fairly new to microservices.

I did a mistake that I have repeated 1593 times in the past. The said link was a resource by one of the big IT service providers.

While the work indeed is commendable - automating 4000 test cases is no joke, the content and approach for highlighting the “best practice” leave much to be desired.

The paper highlights practices that have been assumed to be best practices for a long time - and provides absolutely no information other than to say “we did so and so”. “Extreme automation” is the buzzword of the day, and as we, of the corporate types, agree - it doesn’t get better than that.

I mean - yes, I understand this is a mere case study. I don’t expect every case study or paper to contain all the real “stuff” all the time, but following would have been welcome -

1. How does the accelerator fare as compared to commercial tools today?

• Savings in license costs by avoiding commercial tools (typically clients don’t pay or think they don’t pay for “accelerators”)
• How well did the accelerator write tests? What was the coverage advantage vis-a-vis other tools
• How did developers breathe easy by using this tool as compared to say writing tests in Postman (Pro), or using other open source and free tools that are popular today

1. By how much did the framework improve efficiency in generating data?
2. How was a high degree of overlap achieved in smart sharing of regression/system test cases, while keeping effort and test duration minimal

Take note that I have still not outlined just how I am doing the “thing”. That may be part of the IP, or reflect my “scarcity mindset”. But, readers only get excited about the work when they know more about the advantages of tools and practices employed in the project.

A more complete paper would probably also cover -

1. Employing live vs. test data, and how the framework can help in specific cases. How we found advantage in one or both?
2. How performance tests play a greater role today? How can they be integrated in the overall cycle? How are they automated using existing toolsets?
3. How well can we mock or virtualise services more efficiently given a specific set of constraints?

It’s not all bad

Don’t get me wrong. I can understand where the above content is coming from. Marketing pressures, typical development processes not covering best practices, and lack of resources to think about content strategy through and through - they are all real.

And.. I have been there multiple times. I have been guilty of providing such content, case studies and “white papers” in the past (and probably churn that out again?) - content that lacks substance for so called “expert readers” but content nevertheless. I hope the servers hosting them will burn to ground so that I can lecture on best practices of writing good content. Oh wait, I hope it does not include this website too.

Fortunately, good content is everywhere today. Want to automate your API testing and write something about it? I would say start from these posts -

• know what API testing is about - https://martinfowler.com/articles/microservice-testing/#agenda
• free and open source tools - Integrations of swagger with open source tools including SwaggerAssertions, swagger-test
• how a popular tool aids writing your tests - look up Postman Pro
• how a seemingly successful product helps test automation - https://assertible.com/blog/testing-an-api-using-swagger

In today’s enterprises it is fairly common to have multiple test environments including staging, system / user testing environments and so on. These environments expect production-like features but only for specified users.

For example -

1. Validations have to work as they are in production
2. Document templates and document merge has to work
3. Email and SMS communications have to work for select users
4. Logins have to work for select users
5. A few staging environments may need data in volume - what better data can you find outside of your own production environment?

As is the norm for typical enterprise applications, I tend to -

• keep environments isolated
• build environments on specific branches on demand
• copy over whatever user configuration and user data that are relevant from production

While our build scripts make the build process really easy, the last item for data presents a problem.

For one, we may have sensitive data that has no place in test environments. This data is not meant to be played around by developers, testers and test users.

The second problem is to isolate our real customers from whatever plight awaits their data in test environments. For example, what happens in test environments should stay in test environment, and is not visible/have zero impact on anyone who is not associated with testing.

I try to work-around the problem of data and configuration management post-migration by (trying to) maintain and deploy a bunch of DB/server-side scripts to -

1. Change sensitive fields like emails, and phone numbers
2. Change encryption keys if required and dummify data in pre-identified fields like personal health information
3. Scramble logins and passwords to something different

All this and more is done post data & configuration migration to target environments.

While all the setup activities need to be automated and be part of test migration scripts, I have never really gotten to the nirvana stage here.

Most of the times I end up doing some manual work and stitch together bit and pieces to -

• migrate a part of a huge data-set with quirky data distribution requirements
• migrate specific parts of production while merging that with parts from other environments

I can blame anyone and everyone for that, but at the end of the day, problem lies in my own improper budgeting. Having a lean team (or I alone) focused on a particular solution or project does not help. While the limited people, time and budget gets the work done really quickly and efficiently, there are essentials such as migrations that move to a ‘quasi-essentials’ bucket, and do not get the attention they deserve.

You must have seen the previous post where I waxed eloquent about how I mess up my Rest APIs. There was no way I would be satisfied doing that to a single technology stack.

Ergo, GraphQL.

What is the need for GraphQL?

Google GraphQL and refer docs- there are smarter people with better answers than me.

But, since the Internet can be a scary place and I love to write about things that I am not an expert in - here’s a gist about what I think.

Back to the story..

GraphQL is the SQL for APIs.

Before you say .. ‘ah.. I now know everything!’, read on.

You see - most of the transactions on the web involve fetching some data or the other.

Clients need to be authenticated, authorised and then request data for those transactions to happen. Servers, which supply the data, will comply with client requests based on pre-defined rules.

Rest is an architectural style that allows you to standardize and streamline client-server requests. You can control resources (accounts, contacts etc.) and the operations (GET, STORE etc.).

So far so good. You may even think that you reached a Nirvana state with what has been described so far, but imagine what would happen if you start a series of requests -

You: Give me contacts
Server: Here are 100 contacts with 501 fields per contact

You: Give me contacts and activities for each contact
Server: Here are 1000 contacts and 1 million activities per contact

You: Give me contact detail
Server: Here you go - 1000 fields of the contact
You: Give me address for same contact
Server: Oh God, you again? Here's the address. And, can you please stop this madness?

You will see such examples in the real world - the problems described are referred as ‘over-fetching’ (getting more data than I need) and ‘under-fetching’ (getting less data than I need).

The properties of over-fetching -

• server fetches more data from database (or may query for related entities that are not always required)
• more data is pushed through the pipe
• client gets more data than required and has to process data to selectively pick and display data.

And, those for under-fetching -

• client does not require all data in one-go, requests for related entities or fields
• additional network requests and more needless traffic
• more time to render UI with complete data

The back & forth between server and client frustrates the server - as seen in above conversation, and more importantly, impacts client-side performance.

The multiple back and forth requests make Rest “chatty”.

Ergo, GraphQL.

(I assure you - Matrix has very little to do with me using ’ergo’ all the time.)

Really, why do I use GraphQL?

I certainly do not use GraphQL because it -

• is the in-thing in web development today
• is revered by everyone who say there is nothing more wonderful
• is typed, and that makes it so magical
• provides a really good looking IDE that makes it so easy to develop the queries
• makes services so easy to code (all it needs is a gesture and all the little thingies arrange themselves in perfect harmony)
• drastically reduces chatty network traffic and improves the speed to ‘burn rubber’ levels even before ignition is turned on
• uses in-built security rules that makes it so easy to provide role-based authorization
• is loved equally by server and client tech stacks
• specifies a good abstraction layer for databases
• has subscriptions and those are so so amazing
• is developed by Facebook. I happen to adore Zuckerberg

Or, I may be using GraphQL for a couple of points mentioned above and that is embarrassing to admit (or downright stupid).

The primary reasons for me to use GraphQL are -

• it reduces work on the server-side (surprise, surprise!?). I do not have to write APIs for each and every request, or over-engineer APIs imagining all possible scenarios. Since most of my services are data-heavy, I particularly like the fact that I don’t need to maintain a dozen end-points
• development iterations are easier on client. I can make adjustments to client code to fetch more or less data
• pass only the required data b/w client and server

But, on the other hand -

• GraphQL makes it harder to code server-side services (that is just me, not the fault of GraphQL per se).
• I also find it harder to control the queries that clients request while they snicker in the background (the developers of the said client, not client-users. Since I am the only developer in many of my applications, I snicker to myself about myself. I need help!).

I find it easier to just enable standard Rest pattern to start with (scaffolded most of the time). Then, I start enabling GraphQL services for specific transactions and go from there.

Err.. what are you even talking about?

Let’s see a few examples.

If I need to get a specific contact, I would do the following transaction in REST -

GET https://api.com/contact

The response will be -

data: {
  contacts: [
    {
      planet: "earth",
      name: "Rama",
      age: 42
    },
    {
      planet: "mercury",
      name: "Kris",
      age: 21
    },
    {
      planet: "mars",
      name: "Joe",
      age: 63
    }
  ];
}

I can do the following in GraphQL and send it as a POST request to server -

query {
  contacts(name: "Rama") {
    name
    age
  }
}

The response will be like so -

data: {
  contacts: [
    {
      name: "Rama",
      age: 42
    }
  ];
}

The responses in the two transactions speak for themselves!

What are GraphQL operations? And, why should I care?

No matter what we do in the client-server world - we are trying to do one simple thing -

Share data and business logic b/w server and client

One can query, insert, update or delete data and can initiate those transactions from client. This can either happen -

• with the server not caring about the “state” of the client. i.e., client sends request (with authentication incl. as part of request if required), and server answers the call
• server keeps client interests in mind, has an open channel with the client, and keeps track of data so that clients get changes as they happen

GraphQL builds a layer on top of a database to assist you to transmit data in both cases.

Query

GraphQL queries help you to fetch only the records and attributes you need - we have seen examples earlier.

You can also include different entities (think ’tables’ as an analogy) in the request. Use GraphQL to fetch records with specified relationships, rather than making separate requests for distinct entities.

Mutation

GraphQL mutations are used to insert/change data.

mutation createContact {
  addContact(name: "Joe", age: 100) {
    id
  }
}

The above query provides instruction to use a mutation called createContact that in turn uses addContact to add a contact record with name Joe and age 100.

Subscription

Subscriptions establish a channel between server and client. Clients can subscribe to record updates and get notified (through a simple notification, or by actual ‘push’ of the data from server) whenever there are changes.

Subscriptions use ‘web sockets’ under the hood. This is a battle-tested piece of technology that enables real-time data updates to client.

For example - clients can use the below subscription to get the list of contacts who won the lottery.

subscription listenWonLottery {
  wonLottery {
    name
    deals
  }
}

Let’s see the flow -

1. Clients subscribe to contacts
2. One or more of the contacts get updated in the database when they win lottery
3. On database update, a notification gets triggered to clients
4. The notification contains contact’s name and deals associated with contact
5. Client can thereon show a popup with contact name and show flying balloons for effect

What are the different components required to implement GraphQL?

GraphQL is just the language for API and runtime for executing them queries. It is not hardwired to database and does not specify how the database operations need to be executed.

The different components that implement GraphQL stack are below. These components are not part of GraphQL specifications but are just part of the stack that support transactions using GraphQL.

Server

The implementation/tech stack decides how GraphQL is incorporated in the transaction. Server receives GraphQL requests from clients, establishes connection to database, converts graph queries to a language understood by database, fetches results and sends the responses back to clients.

A server may also include the functions expected from a “normal” server -

• apply business logic to data
• listen to supported types of requests on specified network ports
• takes care of all the supporting infrastructure required to serve requests to clients.

Database

Stores data and maintains atomicity, consistency etc. etc. for data. It is a glorified file system that supports individual transactions and does not mess up the data just because the network went kaput, or your client decided to play a game.

Client

Can be a browser, mobile app or anything that requests data from server and consumes server response to do “something”. We create GraphQL queries, mutations etc. and send them over in a simple POST request.

What are the terms that I should be familiar about?

Schema

A schema is the building block of GraphQL. It is described using a language that we can understand - it can be any language, but a simple option aptly named “Schema Definition Language” is used in the standard implementation.

Consider the below example -

type Contact {
  name: String
  deal: Deal
}

type Deal {
  description: String
  value: String
}

The schema definition helps a client-side developer to see and understand the relationships b/w data entities, and thereon construct a GraphQL query.

Resolvers

A resolver is a function that returns data in the shape specified by schema.

For e.g. -

const resolvers = {
  Query: {
    contact(root, args) {
      return contacts.filter(contact => contact.id === args.id)[0];
    },
    deals(root, args) {
      return deals.filter(deal => deal.id === args.id)[0];
    }
  },

  Contact: {
    deals: contact => {
      return deals.filter(deal => deal.contactId === contact.id);
    }
  }
};

We use a resolver to write queries, mutations and subscriptions.

Object type / fields

In the GraphQL query outlined above -

• Object type is ‘Contact’ and ‘Deal’
• Fields are name, description, and value

This is so cool that I slept through the article. Give it to me straight - should I use GraphQL?

Not everywhere.

Use GraphQL when you need to fetch a lot of data having varying shapes / many relationships. Use GraphQL to simplify the data passed between client and server.

At the same time -

1. Remember that plain Rest API implementations are simpler
2. Even in data-heavy applications, I do not see a big advantage of applying GraphQL everywhere (except architectural uniformity/ standardization, maybe). For e.g. if you have narrow relationships between entities that do not require related data views all the time
3. Keep track of how clients use GraphQL - crazy queries can lead to performance issues

Why do I find Rest services simpler?

1. Endpoint setup is simple on the server. Expose an API or two, and use an ORM to fetch/update data in one or two steps - no sight of fields and related entities anywhere unless you want to deal with them
2. In addition to the previous point, or supplementing it, is the fact that the tooling is amazing - the technology is so old and supported so well that most of the time it just requires a couple of clicks (or lines of code) to fully set up
3. I control queries in the back-end - easier control on who accesses the data and how. I also find it easier to solve potential performance issues since I control filters and sort on the server
4. But all said and done, I may be finding Rest easier since I have spent so much time with it :)

Ok, I am in. Where should I start?

I find the following technology stacks easy to follow and useful to learn for the long run. The recommendations are skewed towards Vue since I use Vue all the time and strongly believe that Vue is easier on beginners.

Enable GraphQL server-side

It is a good idea to create a server on your own and see GraphQL flow in the back-end for real.

Use GraphQL on the client

• Vue + Vue-Apollo
• Svelte + Apollo.

Also see: create a simple to-do with Svelte + GraphQL

Finis

It ends here :)

This is not a theoritical introduction to Rest - there’s something called the ‘Great Internet’ for that. But, what I do want to (cautiously) write about is how I mess up the design principles carefully laid out by smarter people.

Practice 1: Use verbs in resource names

We typically use the following API names -

GET https://api.com/contact
PATCH https://api.com/contact

This is not a problem in the normal course of designing services. But, when it is time to get some complex queries - I always do a rain dance and come up with stupid names.

GET https://api.com/getAccountSalesActivitySummaryForMonth

Best practice

• do not use verbs, use nouns
• represent the resource in the name (if there is more than one resource, pick your favourite)
• use simple URLs

Practice 2: Patterns that no one understands

APIs like below are partly descriptive but make it difficult to maintain consistency in naming conventions.

GET https://api.com/getAccountSalesActivitySummaryForMonth
POST https://api.com/createMaintenanceActivitiesForQuarter
PUT https://api.com/updateAssignmentForDay

Best practice

• already covered in the previous best practice ( I had a brain freeze while starting practice 2 )

Practice 3: Use param in place of a proper URI

If I need a specific activity for a contact -

GET https://api.com/activities/?q={contactId='1-ABC'}

Why do this? Well, I can reuse services on the server side and write same services to -

• bring in the activities for the particular contact (or)
• for any of the thousand queries that a client throws at me.

The practice of using ids as queries is not “standard” and not clearly understood by everyone. I live in constant fear of the maintenance guy ringing my doorbell.

Best practice

The following is most often seen to fetch related records.

GET https://api.com/contact/1-ABC/activities

Practice 4: Use PATCH and PUT interchangeably

I tend to use -

1. Use PATCH if you are incrementally updating the record
2. Use PUT when you want the new record to completely update the previous record - lock, stock and without id (may be?)

But, I have not strictly adhered to the said practice.

There are many who disagree with the PUT/PATCH argument and have been waging a war about where to use what.

Best practice

Follow the above method or otherwise. But, just follow ONE way of doing things.

If you are working in ASP.NET that scaffolds PUT even for a PATCH - get prepared for end of the world. Change the scaffolding or change the tech stack.

Practice 5: Create distinct APIs for role-based filters

I don’t quite know when I started this bizarre practice.

Let say I have to filter data to address the below requirements -

1. A rep should see her records
2. A manager should see her records and her reps’ records
3. A CEO should see no records until the company gets bankrupt

I create three APIs -

GET https://api.com/my-deal/
GET https://api.com/mgr-deal/
GET https://api.com/no-deal/

Internally these fetch data from the same service (getDealsForRole), but only after setting the appropriate filters.

Why do that? I find it easier to manage security and filters in controller/services rather than routes. The resources also are self-contained to manage errors, and can apply complex filter criteria to client-calls or calls from other services (e.g. manager should see reps’ deals but not her private activities).

The problem of applying role-based filters is easily done by using a standard ACL or even by introducing filters, but not all tech stacks have standard ACLs and the damage has already been done for quite a few applications.

Best practice

• Use standard ACLs - if your tech stack supports it. Else, pray and use below alternatives.
• Apply security at the gate and this is at the route-level.
• You could also develop ACL such that the filters get applied without service explicitly requesting for it

Practice 6: Stuff response with everything, you may not get a second chance

My typical service gets to serve related records along with the main entity.

For e.g. -

GET https://api.com/account

The account request may be stuffed to fetch account, account’s contacts and deals.

Normally I would avoid fetching all the data that the client did not request for, but I just hate to do too many requests to server. Without all the data, the client has to fetch -

• list of records
• optionally the detail record at some point of time
• related records

Rather than see the streamlined “fetch”, I include contacts and deals along with the account request. And, before becoming fully aware of what I did - I start throwing queries at database that use some weird joins to fetch all kinds of records everywhere.

• Close coupling of client-server is a problem if you have to serve multiple types of clients. Should never be used for public services
• will reduce traffic but increases payload
• sooner of later I will design a “simpler” service since the main service took so long to fetch results (and the madness continues)

Best practice

Keep your services contained and don’t let them go crazy.

There is nothing wrong in firing a query to get details (they are separate components anyway).

Finis

I will stop here.

Not because I don’t know what other mistakes I make. It is just that I realized how little I know after going through this post more than once.

It is probably time for me to hit that refresh button. I am switching to RPC y’all.

What do I mean by business layer?

Let’s say I have an application running on AdonisJS. For every operation (CRUD) -

• I try to go through controllers/services
• Almost all of them through APIs when called from front-end
• Almost all of the operations through Lucid with exceptions through Database statements
• Use Tasks or equivalent for batches

Everyone does this, why is it a point of discussion?

Going through business layer is good. You can control what gets read or updated when routing through the server layers.

For me personally, the use of business layer has been a cult-like thing.

You see - I had a long history with off-the-shelf applications. These applications foster cult-like behaviour when it comes to database updates. There are far too many things that can break an application for no reason, and the trust on some of the sensitive data (e.g. audit trails) can go for a toss when data updates are not handled responsibly.

Pros / cons

Using business layer enforces good behaviour -

• Follow consistent business rules
• Maintain data sanctity
• Easier to change and maintain (well, this is subjective)
• Easier to do a knowledge transfer to others in the team. Everyone is standardized on business layer :)

In smaller applications that I have been developing outside of my main line of work - this can mean -

• Large scale updates / operations can be a pain - going through layers not optimized for the job can cause memory leaks that had never been found, severe performance issues
• Batched operations are not always first-class citizens of an app (e.g. update hundred records in a batch to minimize database operations)
• Complexity to the code-base when your back-end updates have to (ahem) skip a few rules

In general: wrong tool for the job = conflicts with the larger world and self.

What to do when I am in such a pickle?

• Prefer business layer for ’normal’ operations. Scale the layer for dozens of operations in one go. Implement batch handling but do not go over-board (subjective and overboard definition varies as per your requirements)
• Don’t over-engineer your business layer to handle batch operations
• Rely back on database operations or third party tools (e.g. an ETL)
• Establish checks and balances for frequent third party operations (e.g. apply rules & validate file before the actual update to the database, create automated tasks to review critical data flowing in from external applications)

I still do not understand the problem

Good for you. Get back to work.

MeteorJS was an excellent tool to quickly create universal apps. I was not quite a professional developer back in the day (circa 2016-17) but I could recognize the power of Meteor in developing complex web applications that could potentially deployed for multiple devices.

There was a time when I was flabbergasted as I, rather alarmingly, saw people moving from Meteor to different platforms. I could not quite understand why.

On one hand I was still a believer in Meteor world which could make magic happen and quickly. On the other hand, there were people like Arunoda telling people why they thought it was a bad idea.(Just to get the context right, Arunoda and his team made excellent contributions to Meteor.)

So, why did I like Meteor in the first place -

1. Simple to code
2. Simple to understand
3. Build reactive applications. Server controls sessions and can easily send events to clients
4. A lot of libraries
5. Share server and client code
6. Deploy easily

I faced a few inherent issues-

1. Meteor needed a bigger server. Well, I was comparing to PHP that could happily run a shared server. Even today, I don’t quite imagine using Meteor to smoothly run a data-driven application that I have today on a 2 GB RAM server
2. Development with hot reload was kind of slower for my taste, but nothing significant
3. I don’t quite like the idea of maintaining user sessions (the Meteor way?) - primarily because of the nature of applications I used to build
4. A lot of “dead spots”. Meteor decided to change big time when the users had emigrated to other technologies. With a smaller community the content created on help slowed down. The older content was sometimes applicable or not - which was a constant concern for a then hobbyist developer like me

None of the issues were strong enough for me to stay away from Meteor but at the same time I did not quite embrace it as I have done so with other technologies. Yes, I did experiment with React on Meteor, and VulcanJS,and I know people still recommend MeteorJS as one of the frameworks to evaluate.

So, why? Was/is Meteor a failure? Are such applications a relic of the past?

The answer - no, and no.

Meteor had its time in the golden age of Javascript. There are nuances to why I would rather not go there again -

1. Meteor technology is not as actively developed as it used to be. Though it embraced the latest frontend technologies (think React / Vue), I do not quite see that picking up and going back to its heyday. People are weary of changes I think and they may rather jump on to a train that is already bustling with activity
2. The pub/sub model is the greatest of advantages, but may not be as relevant in today’s world. I love the simplicity of server changes being reflected to “interested” clients, but I can do the same today using web sockets, GraphQL subscriptions and what not. Other technologies have a larger community (= more help) and growing
3. I have increasingly liked the clear client/server separation - primarily due to what I could do with server APIs including consuming them in mobile apps, PWAs, web apps and even desktop apps
4. I am excited about what is happening in the PWA and WASM world. While Javascript has a play in the former, it will eventually get isolated in the latter

Sure real-time applications are easily built on Meteor, but I would see a Vue + AdonisJS / FeatherJS app as equally simple.

There are things that Meteor may not be excellent at, but I am a believer in the model of a full-stack application that can enabled by such technologies. Contrary to beliefs of many a smart people (like what was written by Arunoda), I am a strong proponent to make development tooling simpler. This is done by combining technologies and making magic happen. Given an opportunity of a well-architected full-stack application I don’t believe people will be jumping with joy at the prospect of using multiple platforms to get their application to the market.

In this light - I see Blazor as really promising. Blazor (specifically client-side Blazor) may be the next big thing to accomplish this goal of backend + frontend platform. I can code in a more succinct language than Javascript to spit out the code that can be used by browsers. Equally importantly, I can use the same (or most of the) code for my native mobile apps or desktop apps.

Rust looks equally promising, but I lack the knowledge to comment better. Rust simply does not have comparable tooling as C#.

While there is a core team that stands by Meteor to this day I don’t quite think Meteor’s age will ever come back. I really appreciated what Meteor did for me in the past, but it is time to move on.

1. Type slowly
2. Type (a lot of) mistakes
3. Use spaces and tabs to format. Get confused about loops and add ad-hoc spaces and tabs
4. Curse my typing skills and the soul who invented spaces and tabs

While formatting code was also becoming an interim ’thought provoker’, it was simply too much typing.

Enter prettier.

Although my typing is only half as bad, I now have far less stuff to worry about.

1. Type in any way I want - yes, even type entire program in one line if I am feeling particularly stupid
2. Save file

• Prettier formats code to add spaces and tabs
• Prettier adds stuff that I am lazy to type - (e.g. missing semicolons
• Changes stuff that I don’t do myself - e.g. change single quotes to double quotes
• If the formatting does not happen correctly, I look for coding errors (typically a missing/misplaced bracket)

The savings from all the avoided actions (despite my poor typing) amounts to 1.618 hours a day. That is thousands of hours in my life that can be invested in coding ‘hello worlds’ in new programming languages.

Once you start using Prettier ** you will never go back **. Do that first if you have not done that and come back here.

Following are the ‘Prettier’ settings that I find useful in VS Code (Ctrl + Shift + P > Type ‘prettier’ to search for related settings).

• Editor: Format On Save => True Prettier is not that useful if you don’t see it in action - at.every.save.

• Prettier: Eslint Integration => True Get ESLint to do its thing. Fall back to prettier if there are no ESLint rules. This is mondo useful in languages that are packed with community ESLint rules. I cannot quite hold everyone accountable for the superior practices that I follow. It is far easier to deploy ESLint (or any supported linting) to the development/deployment workflow to make sure every coder follows the same standards. The above flag takes care of any conflicts by using ESLint first and falling back to Prettier if there are no rules.

• Prettier: Jsx Bracket Same Line => True JSX has a lot of ‘>’ and it is annoying if that is moved to the next line. Keep JSX clean.

• Prettier: Semi => True Use semicolons. Don’t believe the evil people who say otherwise.

• Prettier: Tslint Integration => True Similar to the first item on ESLint described earlier, but for TypeScript. Get TSLint to format, and kick into action for stuff that don’t have any TSLint rules.

PS: Yep - the 1.618 is a random number that represents Golden ratio. Did you really think I can ever be so focused on improvements?