So being that this traffic will only be for one day it seems like the best route to go is to buy more than you need.
Do you think I can hit an inner limitation of oplog? Like a logarithmic cpu consumption?
As @jacobin mentioned you’ll have to test this due to the write frequency.
For my specific use case I went from an original 4 writes in 30 min per user. Not a problem. However, it turned into save every change which is like 1 write every 5-10 seconds per user (times thousands of concurrent users (hundreds on day 1)) That wasn’t going to work long term.
Thanks for your advice, really appreciate, I’m starting now on React
I gave Phoenix a try. I like it. I’m intrigued, especially by functional programming. Anyway, I tried both the projects share on GitHub by @ryanswapp and @SkinnyGeek1010 (thanks guys!)
What I kept thinking is why not just write a DDP server to talk to the Meteor client. This way one can simply start with Meteor then if performance is an issue, swap out the server without changing anything on the client.
Then I found this:
A DDP server (not client) written in GO.
@arunoda Are you guys using this? Could this address Meteor performance woes? What are the performance metrics like? Kind of crazy idea is to use this along with @martijnwalraven’s Meteor iOS
Edit:
Though not possible with a Go DDP server, for my own references I’ll collect other interesting projects to replace mongo as well.
Did you by chance listen to the most recent Meteor Club podcast? If not, here’s a link https://simplecast.fm/s/2f11905f21 Josh, Ben, and Sam talked to Chris McCord about Phoenix and he had a lot of interesting things to say. One of which is similar to the DDP server idea. He basically said that Phoenix channels have been designed as low level infrastructure for people to build on top of and they talked about a potential DDP layer on top of that. Interesting stuff.
I personally have been trying to figure out how Meteor would fit in with Elixir and have struggled to come up with viable options. The thing that Meteor is great at is abstraction. It’s abstracted away a lot of tedious things like syncing data between the client and server, authentication, etc… With Phoenix, I’m not sure you really need all the Meteor abstractions. If you can use tools like RethinkDB’s changefeeds in conjunction Phoenix channels and a state manager like Redux on the frontend then I’m not sure where Meteor fits into the picture.
The other thing I wonder about is whether an Oplog tailing/Long Polling type system is really the best way to go. I really like the idea of using Phoenix as a message broker to notify all clients when things change so you don’t need to be constantly polling the database. I’ve experimented with broadcasting events from the controller when something successfully changed and it’s seemed to work pretty well. It’s almost kind of a lazy DDP… haha
Anyways, I’m glad you like Phoenix! Even if it’s not something that we use everyday I think the functional world can teach us a lot about how to build better programs. My code has definitely gotten a lot cleaner since I started working with Elixir
I feel it depends on the application for me. SQL is functional. Data is transformed as it moves from one function into another. Data is the focus. Procedural languages have their advantage too. There isn’t a landslide winner either way. That said, yes, Elixir is refreshing.
I have, interesting talk for sure!
Right, but the aforementioned DDP projects is a Go DDP server not a client. It means it speaks DDP to DDP clients. Be this a Meteor client w/ React or Meteor iOS.
There are nuances that typical “real time” apps often overlooked.
With a DDP Server (not client!) written in Elixir or Golang, it seems to me much of the performance problems for high-traffic application can be resolved. This further supports the idea that Meteor is indeed a very good choice in the beginning given that the problematic parts can be swapped out when needed.
To rehash: At the heart of Meteor is the DDP protocol. There are many clients that rely on a Node server; yet it is quite possible to have a server written on something else. Perhaps Golang?
By this “In a follow up post we will use RethinkDB Changefeeds and Phoenix Channels to make our app realtime” I was just trying to let everyone know that I’d be doing a third post on using changefeeds with channels to make the simple app we built real time. The app built in that post isn’t realtime (yet - the third post I’m planning will make it that way). Sorry if that wasn’t clear!!
@jacobin@kaiyes I am still planning on the video series!! It’s been a bit delayed because I’ve been experimenting with different approaches to building apps with Phoenix. I’d like to nail down a solid implementation before I make a video series on it.
Now, that’s not to say that the template I made is a bad implementation. I just want to get a little more comfortable with the technology so I have some value to offer. I’ve got a bunch of free time tomorrow. I might look at pumping out some material. We shall see
I’ve decided to start a tutorial site that I’m currently building so you can plan on that popping up in the next couple of weeks. It’ll focus on Meteor, React, and Phoenix development. Some of the videos I’m planning will discuss my new boilerplate and how its setup. In addition, I’ll show how to build the template for production and deploy it to S3 or Github pages as a static site that talks to a Phoenix API hosted on Heroku.
Ya I saw that! Had to upgrade to Node 5.4 to create a new app (which is good). Do you know if Brunch creates client bundles for you? Or is it like Grunt/Gulp where you have to run your code through Browserify?
I’m really comfortable with Webpack now and it is amazing so I don’t think I’ll be switching any time soon. I also don’t think Brunch supports hot code reloading?
That said, if I build an app without a React frontend I’ll most likely just use Brunch
Ya it looks pretty straightforward. The only problem is that the vast majority of the react ecosystem uses webpack so all the tools are designed around webpack. I used to not be a big fan of webpack but now I love it! Tough learning curve for sure, but it’s a great build tool.
That wasn’t going to work long term.
I used to not be a big fan of webpack but now I love it! Tough learning curve for sure, but it’s a great build tool.