“The only real mistake is the one from which we learn nothing.” – Henry Ford
It is important to share our experience to help others avoid stepping into the same bucket.
It was an enterprise distributed project with a small group of developers. Each developer had a different part of the solution to develop and at some point, all of us concentrated on the backend.
- In some (bad designed) case authentication tokens were sent in a query string as a part of the URL. Please don’t try it at home, it’s like sharing your username and password with the world. Anyone who will get the URL will be able to access the protected resources.
- In memory caching for distributed solution – that might work if you manage to sync the in-memory caches between different nodes, but that was not our case. If you would like to get a bit more information about different caching options please check here and here.
- Complicated, bad organised and annoying caching system – in most cases we had a lot of dependent cache but in order to clean the dependent cache, we had to write a lot of boilerplate code. However, upon Insert, we could add CacheDependency to simplify the solution for example.
- We used EntityFramework to work without MSSQL database – but most of our developers were not familiar with “Performance Considerations for EF 4, 5, and 6“. This led us to quite slow queries without cached query plans and etc.
- We ended up with a lot of copy-paste queries – a violation of DRY principle.
- We had to write a lot of boilerplate code on each request – DTO -> SQL Query -> Entity -> DTO. One of the possible solutions here would be to use Automapper.
- A mix of RESTful and RPC.
- Almost RESTful – where POSTs used to return data (query).
- Conflict of interests:
- SOLID principles were totally ignored.
- 0 automated tests.
- DRY principles violated.