
Ask HN: How should I develop my CMS / Back end? - kanaade
I&#x27;ve been working on a backend in PHP for the past year, expanding and changing it every time a customer needed new things that were not previously covered by it. I was using Laravel because not only I felt comfortable with pbp but also I really liked how easy it was to implement new functionality.<p>Now the time has come where I have to step up a notch, change the backend design and extend it a lot further to support an incoming wave of new clients that expect something more than what I&#x27;m currently offering.<p>I&#x27;ve been digging HN a lot and reading about everything that could help me here and I opted for using GO for the backend. The idea would be to write all the functionality on GO, users, db and such and write the frontend with AngularJS connecting it through a rest-like API. I don&#x27;t have right now the time to learn GO and rewrite everything I made on PHP, but I plan on doing it in the next 6 months.<p>Right now I&#x27;ll be writing the backend again in Laravel I think, but only the functionality. My idea is to make an API and have the frontend with AngularJS connect to it using post&#x2F;get to do everything. This way I can isolate the backend from the frontend and eventually rewrite the backend in go without needing to touch the frontend in Angular.<p>Does this make any sense? Is this, a good way to approach this although its maybe not the best one? What are your thoughts? Thank you!
======
detaro
What motivates you to rewrite it in Go? / What benefit do you expect from it?

Moving things towards a clear API is a good step towards replacing a back-end.
I won't comment on the choice of Angular because I don't know enough about
front-end development and it really depends on the type of product what fits
well.

~~~
kanaade
Well, after some research it seems Go is pretty fast for starters. The backend
I'm building is expected to be accessed by more than 10k people on a daily
basis so it has to be robust. One of the other features I'm really looking
forward is the built-in web server it offers. Basically I heard it's strong,
scalable and neat for a service that needs a lot of requests per day, so it
seems like a good idea to give it a try.

~~~
benologist
Those are all great reasons to try it on a different project, and terrible
reasons to rewrite your functioning, complete software.

