Yes I understand where you coming from now, but that is what I was proposing, we have that setup as well with some apps using SimpleDDP (or you can use GraphQL) and Create React App but you can use any front-end framework.
The advantage here is that you have an optional real time, accounts, SSR, hosting, and rich ecosystem with JS end to end.
I have tried GoLang and I wasn’t sold on using it for web development, if I decide to branch out of Node I would pick rust or Deno instead but of course Go will get the job done (or any other back-end framework for that matter, Akka or Spring for the JVM or even .Net would have been good choices here).
I enjoyed the conversation as well, and thanks for sharing your work, yes I’m interested in your books aggregator, we can a chat on this on slack or another thread I have some ideas on this topic
if I decide to branch out of Node I would pick rust or Deno instead
Rust is a nightmare in development, ugly in syntax but perfect result. Deno… It’s just like nodejs but from other point of view, how could it be used in node branching?
we can a chat on this on slack or another thread I have some ideas on this topic
Unfortunately I don’t use slack (in company we use local mattermost, so I dropped using slack) but you can find me in skype - andrew.manson.noperapon or just write me an email to manson.andrew @gmail.com
Yeah, I don’t like Rust syntax either, but if I’m sacrificing the full-stack JS advantage, might as well get a perfect result. For Deno, it is the the same as Node (and that’s not a bad thing for me) in a sense that it runs on V8 but it is different enough in the API and architecture to worth exploring, at least for me, so I would give it more credits and keep a closer eye on it.
What do you mean by socket? Websockets? Since you mentioned you projects from long time ago are you using mongo oplog? Is it enabled in production? Can you share information of profiling you did to find bottleneck? It would also be nice if you could share the code that improved performance, maybe someone who works on meteor core would take a look at it.
Since you mentioned you projects from long time ago are you using mongo oplog?
A far as i remember, no special mongo switches was used. Just default mongo instance as it was after installation (there was some other projects running on it)
Can you share information of profiling you did to find bottleneck?
Never thought It would be useful for someone else so nothing stored. As Meteor rose from the ashes with a new team I’ve just interested in that I’ve stumbled here a time ago.
It would also be nice if you could share the code that improved performance, maybe someone who works on meteor core would take a look at it.
Don’t think this could be useful because I didn’t improve the existing core of Meteor, I’ve just rewritten it (to be more precise - application’s server logic, not meteor’s. I’ve just stopped using meteor’s engine and its DDP - switched it off) by using the side socket server and most logic. The meteor’s server side part (in javascript) that uses this separate socket-server is a simplified version of the similar logic the meteor’s team has implemented.
