1

I have been assigned to a project where the end-product is a website as a music community. So it's uploading of music, sharing it amongst other users, listening to music from the website and so forth. It's a project that will not cross the borders of this nation, that's certain, so the scaling part is really not interesting.

At the moment we have ~12.000 users total, so it almost nothing.

That being said, for me it's a really simple and straightforward product. But we all know that simple can be ruined by a lot of things.

My problem with the codebase is the many obscure layers. We start of by loading a "shell" and from there we do like this:

HTML/AngularJs -> TypeScript -> Breeze -> WebApi/OData -> Entity Framwork

So really, my question is whether it's just me or if I am correct in my mind when I think this is totally over-architectured. And has someone else has seen an architecture like this and would you agree that cutting away the typescript + breeze abstraction would be the way to optimize the architecture ?

Having seen something like this I have lost some faith in TypeScript, because it is really hard for me not to see it just an abstraction between connecting some frontend framework and some backend framework, instead of them just "talking together" with TypeScript in the middle.

Improve this question
3
  • TypeScript is just a tool to make your code safer (compile-time error checking) and more refactoring-friendly. This "abstraction" totally goes away at build time, at runtime there's just JavaScript and nothing to "optimize". You are the programmer and you can modify the architecture anyway you and your team see fit. If you ask why is it useful to think in replaceable components and architecture layers with well defined responsibility at all then perhaps pick a good book or just don't care and do it your way. I'm missing some non-opinion-based answerable question in your writing
    – xmojmr
    Mar 17, 2015 at 12:09
  • If they "talked together" directly the whole thing would probably be less maintainable in the long run. The types provide information; documentation that could otherwise be missing or (even worse) inconsistent with the code base. You may not appreciate it now, but other developers (including you) will probably appreciate it in the future.
    – Trylks
    Mar 17, 2015 at 13:18
  • 1
    That's a powerful stack. Each component has benefits. AngularJS gives you a powerful client-side MVVM framework for building and data-binding interfaces. Typescript allows you to write front-end code more intuitively. Breeze helps you manage data between your web services and client and can yield significant performance benefits. Sure, you could feed data from your services directly to your client-side for presentation, and with a small app there's nothing wrong with this. As this application scales, though, you'll find yourself running into problems that this stack already solves.
    – ravibhagw
    Mar 17, 2015 at 18:37

1 Answer 1

Reset to default
7

It's dangerously easy as a programmer to start thinking that every project you encounter could and should be done better (read: rewritten) because it doesn't correspond to your vision. We've ALL been there.

You look at code and your mind just goes into "what's wrong with this"-mode, instead of focusing on what's right about it.

If you start plucking away at the components, how much time will you lose? Time you were assigned to spend on the actual assignment.

Do you have any guarantee that removing components X or replacing them with technology Y will increase performance, scalability, maintainability?

It seems to me that a web application of this nature could certainly benefit from most, if not all, components it appears to have: O/RM, caching strategy, strong typing, REST capabilities, some mobile-ready features, ...
The pertinent question is not "should this project be made up of components X, Y and Z but rather: was it well written? Does it make sound use of said components?

You didn't mention for how long you have been and will continue to be working on this project, but to me an architectural redesign or component swap-out should be a last resort after you have thoroughly examined the application, made it your proverbial home (and this preferably takes a lot of time and research), whereas it sadly tends to be out with the old, in with the new.

So, in the end, it's not up to us to decide but up to you. Just be careful that if you decide to go ahead and redesign / swap-out / rewrite, you do it for the right reasons.

Improve this answer
3
  • You're absolutely rigth, and I didn't want to sound like the developer that pointed fingers, because that's not the way it works. I think my concern is mostly regarding productivity, given the amount of code I need to add for a very simple feature. The abstractions I need to add code too is many and I would like to skip a few of them to add more joy and a leaner codebase.
    – frostings
    Mar 17, 2015 at 9:03
  • Neither did I imply that you were pointing fingers but if you code around some of these abstractions now, you'll end up with an application that uses two distinct ways to get things done. Imho, that's even worse. More difficult to read, even more confusing in the future.
    – Wim Ombelets
    Mar 17, 2015 at 9:21
  • @frostings typical answer to the problem of "amount of code I need to add for a very simple feature" is code generator. For example complete WSDL consumers/producers are code generated, otherwise that lots of bugless glue code one has to create to keep it up and running in order to allow the systems to talk to each other is awfully huge (and that's why so many people dislike it)
    – xmojmr
    Mar 17, 2015 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.