DEV Community

loading...

How not to architect your project? 

vaidhyanathan
Coder, solution and framework designer.
・2 min read

I have been working with some of the most successful products in the Saas Industry. Here are some of the things I used to say a big NOOO ! Probably you must also do the same.  

Wrong framework

Know your product and usecase and choose the correct framework. Choosing GoLang for web app development and ruby for high performance code is wrong . Have a good knowledge on all the frameworks and languages, choose wisely. There is no going back on this.
I see people choose Java for webapps because thier employess only knows Java, but inreality Java is no good for webapps.

Using V1.0

In the year 2013–2014, When asked people not to use angular they used to mock at me. After a couple of years Google ended it support. Simple Thumb rule is dont use any new frameworks/tools/standards till thier version 2.0/ atleast stable for 3 years. First few stable versions also will be having architect failures most of the times. So use some standard approach. 

Hyper Scalabilty 

 Yes your read it right. People tend to perfect thier product to scale millions of request per second, but in reality it wont happen soon! Customer aquestation is a gradual process and it takes time to reach potential users. Even a killer product will take couple of years to pick up first few thousand active customers.So all the scalability efforts put during the initial products are worthless. It's like you made the yummest recipe but no one is there is take it.

Nanoservice(Heavy microservices)

Writing eveything as Microservice is the one of the things that usually kills the product soon. Microservices is only recommended if your product has a mamoth code base, which basically needs to be splitted to microservice ,and your are having resources to maintain. Starting the product with everything as microservice service which is a overkill. My recommendation is to start as modular monolithic and move to microservice if necessary. 

Refactoring

Refactoring the whole code base is wrong. If there was some wrong decision taken in initial days, do refactor as much early as possible. Refactoring too much is a bug prone , vague and non productive job. Customers dont care what is behind they only see if things works. These kinds of problems can be solved by having a good Architect. 

New Inhouse solutions

We cannot solve all the problems , even we have resources and talent. If there are some ready made solution, Please use it. It is not because of saving money. It is because existing solution usually takes all the learning from the community or customer. I saw many projects used thier inhouse search service instead of elasticsearch or Solr, With in couple of years they failed and return back to the open source solution. 

The above are the major things I used to say a big no while designing new product.

Please add your suggestions also below.

Discussion (2)

Collapse
vaidhyanathan93 profile image
vaidhyanathan Author

The major advantages of java is portability. But Webapps we wrote these days are running either on docker / same set of containers/VM. which basically omits the need for java

More over, Java is too heavy and requires much time to write code, which in dev prespective it is a lot of work.And more over java is very late for many things like Lamda, streams much more came late after Java 8 only. Framework like Spring are not evoloving as fast as other web frameworks.

I worked on both Spring and rails. I feel rails is more powerful and easy than Spring framework.