5 ms·

The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of

The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed. But maybe I'm wrong, that's just how it looks like from the outside.

s_kilk 11y ago
Same. Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.
- cmdkeen 11y ago
  I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.
  - ploxiln 11y ago
    I think it's interesting to consider the reasons why that is. Why are backends typically slowly upgraded while maintaining a compatible API, while front-ends undergo big re-designs and re-writes from scratch just about every year? At commercial, successful startups? One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully similar to the yearly fashion cycle. But are there other reasons?
    - ThrustVectoring 11y ago
      Front-end systems have more room for creative expression, drawing in more of those who want to express themselves with a major overhaul. Furthermore, the base skills of front-end developers are more of "understanding how humans interact with user interfaces" and managing complex state. Back-end developers tend to need more understanding of the problem domain and communication skills, so the developers that do better at back-end work tend to build things that need less updating. Basically, I'm asserting that front-end and back-end work attracts different kinds of developers. Back-end developers are less likely to write things that need replacing, and front-end developers are more likely to want to replace things.
    - s_kilk 11y ago
      Data is forever. If you've got a working model (and system) for Users, Widgets, Gizmos and Sprockets, then there's little reason to change. New client devices come and go though, and users expectations of a good interaction experience change, and once your backend is solid you can quickly throw a new skin over it and view/interact with it in a new way.
  - pm24601 11y ago
    I used meteor for 2 years professionally. The issue that you raise is less important with meteor because updating the server code updates the client code.
ollysb 11y ago
Not to argue your point about the options being limited, but support for rethinkdb is in progress.
bhouston 11y ago
> What happens if suddenly I want to rewrite part of the back-end or part of the front-end Which is likely what is happening right now to detriment to all those that have already adopted meteor. But you sort of have to need to do this.
eterpstra 11y ago
Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate coding. For small teams with outsized requirements, it's a perfect fit. I've built a couple (internal) apps with Meteor and got a tremendous amount done in a short time. Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the time savings earned now are worth the technical debt that I might face in the future.
- debaserab2 11y ago
  > but the time savings now are worth the technical debt that I might face in the future Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.
  - eterpstra 11y ago
    Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
  - nostrademons 11y ago
    Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth. Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders. [1] http://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf http://static.googleusercontent.com/media/research.google.co...
davnicwil 11y ago
> What happens if I want to switch from MongoDb to.. Postgres.. The default choices with meteor are pretty fixed This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing. I believe SQL integration is on their roadmap, but I think now it's too late. You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along. I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.
- bjourne 11y ago
  Query subscription is the reason. You can add a monitor to the equivalent of "select * from docs" in mongodb and get notified by the db when a docs row is inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it is not the same and is much more resource intensive. That makes it hard to achieve Meteor's goal of "any data change is immediately reflected in all clients" with any db other than mongodb.
  - Lazare 11y ago
    It's actually even easier in CouchDB than Mongo. One of the smaller mysteries to me has always been why Meteor went all-in on Mongo rather than Couch.
pfooti 11y ago
Yup. When I was researching front-end / back-end stuff three years ago for the project I'm still working on, meteor was on the list. It's neat for sure, but I didn't want to be stuck with mongo as a forever thing. I ended up in a more fragmented place - node on the back-end with a lot of libraries (hapi.js, knex.js as two major ones) and angular plus a lot of extra code on the front. On the plus side, everything in my project works well, smoothly and exactly how I want it to work. Plus: referential integrity in the data model, since it's postgres back there. I even get live updates from the server to the frontend using postgres listen/notify and websockets. It took more time getting there, but ultimately I'm one of those Other kinds of devs - I don't want one big opinionated framework, I want a lot of littler pluggable bits. But that's okay, there's room in the world for both.

s_kilk 11y ago

Same. Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.

cmdkeen 11y ago
I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.
- ploxiln 11y ago
  I think it's interesting to consider the reasons why that is. Why are backends typically slowly upgraded while maintaining a compatible API, while front-ends undergo big re-designs and re-writes from scratch just about every year? At commercial, successful startups? One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully similar to the yearly fashion cycle. But are there other reasons?
  - ThrustVectoring 11y ago
    Front-end systems have more room for creative expression, drawing in more of those who want to express themselves with a major overhaul. Furthermore, the base skills of front-end developers are more of "understanding how humans interact with user interfaces" and managing complex state. Back-end developers tend to need more understanding of the problem domain and communication skills, so the developers that do better at back-end work tend to build things that need less updating. Basically, I'm asserting that front-end and back-end work attracts different kinds of developers. Back-end developers are less likely to write things that need replacing, and front-end developers are more likely to want to replace things.
  - s_kilk 11y ago
    Data is forever. If you've got a working model (and system) for Users, Widgets, Gizmos and Sprockets, then there's little reason to change. New client devices come and go though, and users expectations of a good interaction experience change, and once your backend is solid you can quickly throw a new skin over it and view/interact with it in a new way.
- pm24601 11y ago
  I used meteor for 2 years professionally. The issue that you raise is less important with meteor because updating the server code updates the client code.

ollysb 11y ago

Not to argue your point about the options being limited, but support for rethinkdb is in progress.

bhouston 11y ago

> What happens if suddenly I want to rewrite part of the back-end or part of the front-end Which is likely what is happening right now to detriment to all those that have already adopted meteor. But you sort of have to need to do this.

eterpstra 11y ago

Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate coding. For small teams with outsized requirements, it's a perfect fit. I've built a couple (internal) apps with Meteor and got a tremendous amount done in a short time. Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the time savings earned now are worth the technical debt that I might face in the future.

debaserab2 11y ago
> but the time savings now are worth the technical debt that I might face in the future Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.
- eterpstra 11y ago
  Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
- nostrademons 11y ago
  Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth. Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders. [1] http://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf http://static.googleusercontent.com/media/research.google.co...

davnicwil 11y ago

> What happens if I want to switch from MongoDb to.. Postgres.. The default choices with meteor are pretty fixed This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing. I believe SQL integration is on their roadmap, but I think now it's too late. You can in fact use React as the view layer with meteor, so for an app using React, the remaining killer feature of meteor 6 months ago was optimistic updates, with database sync all handled. But, there was still the hard limitation that you must use it with Mongo, which simply made it a no go. I commented about this here, a couple of times, and others did too. I even asked a few months ago if there was a library that just provided the optimistic updates feature. Well, now there is one that looks promising, though it's still early days and I've not used it yet - Facebook's Relay - with complete React integration, caching, request management and optimisation, and yes, optimistic updates and sync. The difference though, is that it talks to a graphql server, which can be written over any database at all - with Relay the frontend is entirely agnostic about the database used, by design, because it talks to it through a middle tier. There's no reason for me to wait for meteor to implement SQL integration any more, because now another solution has come along. I still don't understand why meteor made the choice of a hard dependency on Mongo if they ever wanted to become mainstream. Had they not, it's very likely that many developers, myself included, would have picked up meteor over the past year and would be hooked on it. Now though, that train is rapidly leaving the station, at least for devs on the React stack. I think they missed their window.

bjourne 11y ago
Query subscription is the reason. You can add a monitor to the equivalent of "select * from docs" in mongodb and get notified by the db when a docs row is inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it is not the same and is much more resource intensive. That makes it hard to achieve Meteor's goal of "any data change is immediately reflected in all clients" with any db other than mongodb.
- Lazare 11y ago
  It's actually even easier in CouchDB than Mongo. One of the smaller mysteries to me has always been why Meteor went all-in on Mongo rather than Couch.

pfooti 11y ago

Yup. When I was researching front-end / back-end stuff three years ago for the project I'm still working on, meteor was on the list. It's neat for sure, but I didn't want to be stuck with mongo as a forever thing. I ended up in a more fragmented place - node on the back-end with a lot of libraries (hapi.js, knex.js as two major ones) and angular plus a lot of extra code on the front. On the plus side, everything in my project works well, smoothly and exactly how I want it to work. Plus: referential integrity in the data model, since it's postgres back there. I even get live updates from the server to the frontend using postgres listen/notify and websockets. It took more time getting there, but ultimately I'm one of those Other kinds of devs - I don't want one big opinionated framework, I want a lot of littler pluggable bits. But that's okay, there's room in the world for both.