Wednesday, March 26, 2008

What to use for the front end?

Here's an interesting technology question that's come up.  Right now we have our main product built in ColdFusion.  We hate it, primarily for performance and stability reasons - finding it difficult to scale it and keep it running consistently.  Is that because of operational issues, or just bad codebase?  Dunno.

For a handful of random projects we've used Ruby on Rails.  Most notably this includes our Facebook application.

We've already decided to make the move toward a more service oriented architecture, with .NET being the backend.

The question came up today, "Does that mean we have to use .NET as the front end, too?  Why?"

Good question.  Technically no, I suppose you don't.  If you're doing proper services on the backend then you can use a variety of client technologies.  But then the question is, which one?

.NET is the logical choice purely out of convenience.  You're going to have a team of developers in VisualStudio all day, so why make them have two entirely different development environments?  That seems like the way Microsoft took over the world back in the 90's -- yeah, our product X isn't really that good, but you're already using product Y, and they work nice together, so why not just go with it?

Rails would be a bold choice, since this would mean putting the company's main revenue source onto the technology instead of just the occasional side project.  It's one thing for one guy to bang out Ruby code as needed, it's another for an entire team to develop a product in it.

What about ColdFusion?  If relegated to just the front end, would it be a viable option?  Would the scalability and stability problems go away if we took 90% of the code out of it and started over?

Would you bring PHP into the mix, where it currently does not exist?  What about Java?  The product's not technically in Java now, but ColdFusion runs on a Java app server and most of the coders here are proficient in it.  So that, too, is an option.

Without a better case for something else, right now .NET is going to win.  It'd be nice if it didn't, though.


steveo said...

Using the same language on the front end and back end can have serialization advantages. Some generic serializer/deserializer that may only have an implementation in a specific language can be used. Also the same objects can be written front end and backend and used in both places.

The only sane way to use different front end and back end languages would be to use WSDS with code generation.

steveo said...

That would be WSDL

Duane said...

Well that depends on whether you're talking SOAP or REST. The latter would be a little bit more language agnostic when it comes to that sort of thing.

As for sharing objects between front and back end, sometimes I wonder if maybe the discipline of not doing that is a good thing. What if my server team were in India and my frontend team were in Chicago? I think I'd prefer that they each be as self sustaining as possible and not constantly be saying to each other "Did you change the User object on me?"
Services allow you to publish the API and then both sides can say "As long as we agree to speak that API we can both do whatever we want."

steveo said...

If you have that kind of requirement, then you absolutely have to use WSDL. You publish an XML document (WSDL) describing the fields that will be translated. Tools for pretty much any language can read that standard file and generate objects for that language that are compatible.

Its the way to go if you are publishing SOAP for any old Joe to devlop against. It is still more complex than just using the same objects on both ends in the same language though.