Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 1: What Went Wrong

discovermeteor.com

Post reply on HN
Print view View original

171–180 of 189 posts

Re: The State of Meteor Part 1: What Went Wrong

#171

Post by extrapickles »

rashkov wrote: post #166
extrapickles wrote: post #124

Earlier quoted context omitted.

I currently use Meteor for a production app, but only use Mongo as a scratch pad (holding data until the user is mostly done changing their mind and other minor UI state). Data is then packaged and sent to MS SQL Server for long term storage and reporting. As an example, a user can start updating a piece of data (eg: sales order, item, etc), with everyone able to see the changes as they happen (no hard need for locki…

This is very interesting. Could you give a little more details on how you accomplish this? How do you serialize unstructured Mongo data into MS SQL? Does this system break down when front-end people change the data structures in Mongo? I'm not familiar with Meteor but maybe you could explain in broad strokes

There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and effectively lets us use merge-style replication techniques, and support temporary offline use of our application.

If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type mapper is needed.

The lumpy data case gets more complicated, as its dependent on the data. The complex data generally ends up translating into master/detail tables or similar ideas. Various pieces of data that is nice to have, but changes with the UI/customer needs, gets stuffed into several key/value tables (one for each type).

For the completely dynamic Mongo data we store in SQL, we alter the SQL table programmatically to meet the new schema (in part of our application, customers must be able to drive the schema). This way works in our specific application, but it requires a lot of work to make sure your users cant paint themselves into corners with their schema.

So far we haven't experienced any issues with the front-end people changing data structures, as the changes they generally make only impact fields that are not stored in SQL. Completely new features generally require the addition of new columns/tables to SQL, but every application has that issue. During startup of the server it double checks the schema of all of the tables used and updates as needed.

Re: The State of Meteor Part 1: What Went Wrong

#172

Post by bpicolo »

explorer666 wrote: post #95
ams6110 wrote: post #70

Earlier quoted context omitted.

It's why PHP still thrives.

Or because it's a mature language, with a robust, very rich and up-to-date ecosystem.

It's really not very rich and up-to-date, in my opinion. In my experience, the vast majority of oss PHP projects started a decade ago, and they all keep certain back-compat, so they run with the drag of old paradigms. Actual new contribution to the ecosystem seems almost impossible to find, and there's a lot of areas that simply aren't great.

E.g try to find a sane way to work with PostgreSQL json,jsonb columns in a safe way in php. There's no even halfway decent solution. Half-supported, roll-your-own in doctrine is the best you can get

Re: The State of Meteor Part 1: What Went Wrong

#173

Post by jrochkind1 »

fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

> If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about

Except if you chose Blaze and that happened, you're stuck with a bunch of code written for a thing that is no longer used (by anyone except people like you, nothing new is happening with it), which is in fact a somewhat threatening place to be.

Re: The State of Meteor Part 1: What Went Wrong

#174

Post by pfooti »

realusername wrote: post #9

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 wit…

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.

Re: The State of Meteor Part 1: What Went Wrong

#175

Post by spdionis »

magicmu wrote: post #44
scient wrote: post #32

Earlier quoted context omitted.

So why did you pick a tech stack for this project, given that you had not used it before, sounds like no-one in your team had either, nor is this stack widely used (afaik)?

It seemed to fit our use-case really well. The CTO and I did a Meteor hackathon to get a feel for the tech, and thought that it would be a lay-up. Alas, it was quite an error.

Don't evaluate a technology after having used it only during a couple-days hackaton.

Re: The State of Meteor Part 1: What Went Wrong

#176

Post by e12e »

heliostatic wrote: post #88
wsvincent wrote: post #75

I'm currently using Meteor to teach a college-level course on Web Development for beginners. https://csci16.hellometeor.com/ It's incredible how accessible Meteor is for this purpose: * One line complete local setup * One line deployment (to Meteor servers, but still) * Javascript only (no need to learn Python, Ruby, etc in addition) * Out of the box User Accounts * Simple templating engine with Blaze I can think of…

I'm biased as the co-teacher, but I've been hugely impressed by progress our students have made in just three weeks. Meteor really does fit in well to the beginner curriculum.

Looking at the course page, it does indeed look like meteor is a good fit; it appears that if the course was from the late 90s it would be 2 parts html, 1 part css and 1 part cgi.

But for a little higher level I always liked web2py[1] - it always felt like they managed to balance bundling/simplicity with proper documentation that build confidence in what is (and is not) included: like having a db schema accompanying the section on built-in auth[2].

But it certainly fails the test of "just one language". And it appears their chosen host (pythonanywhere) need to fresh up their SNI/SSL handling.

[1] http://www.web2py.com

[2] http://web2py.com/books/default/chapter/29/09/access-control

Re: The State of Meteor Part 1: What Went Wrong

#177

Post by spdionis »

heliostatic wrote: post #88
wsvincent wrote: post #75

I'm currently using Meteor to teach a college-level course on Web Development for beginners. https://csci16.hellometeor.com/ It's incredible how accessible Meteor is for this purpose: * One line complete local setup * One line deployment (to Meteor servers, but still) * Javascript only (no need to learn Python, Ruby, etc in addition) * Out of the box User Accounts * Simple templating engine with Blaze I can think of…

I'm biased as the co-teacher, but I've been hugely impressed by progress our students have made in just three weeks. Meteor really does fit in well to the beginner curriculum.

I always ask myself in these cases, what do you mean by "progress"?

Re: The State of Meteor Part 1: What Went Wrong

#179

Post by rashkov »

extrapickles wrote: post #171
rashkov wrote: post #166

Earlier quoted context omitted.

This is very interesting. Could you give a little more details on how you accomplish this? How do you serialize unstructured Mongo data into MS SQL? Does this system break down when front-end people change the data structures in Mongo? I'm not familiar with Meteor but maybe you could explain in broad strokes

There are several ways we go about it depending on the needs of the data to be stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key and effectively lets us use merge-style replication techniques, and support temporary offline use of our application. If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type mapper is needed. The lumpy data case gets more complicated, as its d…

thanks very much for the explanation. That sounds like interesting work and a great solution

Re: The State of Meteor Part 1: What Went Wrong

#180

Post by davidw »

ibarreto wrote: post #178
davidw wrote: post #54

When I saw MongoDB, Meteor got put on a "check back some day" list. Phoenix is way more interesting: it's built on some very solid foundations.

Phoenix the Elixir framework? Or something else?

Yes, that Phoenix. Granted, it's much newer than Meteor, but it builds on such a great base that it really is standing on the shoulders of giants.
Post reply on HN