Hi all,
I was playing with mantra in the previous days and there’s one topic that confuses me. It seems there are 2 place for methods: server/methods and client/modules/**/configs/method_stubs. Should I write a method stub for every method to get latency compensation? Are Meteor’s isomorphic methods considered bad practice? If not, where should I put them in mantra’s directory structure?
Thanks!
Yes it is. But you can use the logic inside it imported from a common place.
Thanks!
Do you know any example apps that uses this pattern (import logic to methods)?
Am I right that it should look like this?
/common/methodLogic.js
import {Posts} from '/lib/collections';
export const create = (title, post) => {
Posts.insert({title, post});
};
/server/methods/post.js
import {Meteor} from 'meteor/meteor';
import {create} from '/common/methodLogic.js';
export default Meteor.methods({
'post.create'(title, post) {
create(title, post);
}
});
Yep. This is correct here. The reason for this is that, client and server should be two different things and they should not share anything implicitly.
This is a kind of hard choice, but that’s the way how new apps works. When Meteor’s Apollo comes out there’ll be no things like this kind of isomorphism.
I’m not so sure. Personally I am a huge fan of isomorphism. My favorite thing about GraphQL is that the server exposes a lot of useful information about the API that the client can use to make the developer experience better. And once everyone standardizes around NPM and a single module system, it will be easier to share code between many clients and servers than ever before. I’m curious to hear what caused you to have such a deep distrust of sharing code, because in my mind it’s getting better and better now that everyone is starting to use the same JavaScript (such that Meteor 1.3 modules are compatible with Webpack, Browserify, Node, React Native, etc.)
No you got it bit incorrectly. This is what I mean by this kind of isomorphism.
Rigth now, with Meteor method, we simply write the same thing both client and the server. With GraphQL, server is a black box. Everything should do on the server should expose with GraphQL. (or something kind of endpoint)
This is also true with REST endpoints.
That’s why we are trying with this approach. So, client don’t know how the server works and but it has some information on how it can be. Client code will never be run in the server. (except for SSR)
Yes. 1000x this.
There’s going to be a lot of pushback against ditching isomorphic APIs for amorphic ones. There’s a reason people adopted Meteor’s vision of Javascript over NPM and others. And ismorphic APIs are top-and-center of the list.
Tossing out Isomorphism is tossing the baby out with the bathwater. Sorry, Arunoda. Gotta disagree with rather strongly on this one.
That’s totally fine. This is what really happening everywhere. Eventually, this is what’s going to happen in Meteor too.
You should consider server and client two different things. If you wan’t do isomorphic, use common modules which can use run everywhere. There are places we can’t do 100%, but Meteor methods is something we can start with.
Try visit this thread after 6 months, you’ll get why I say so 
I think we should stop thinking of things as “client” and “server” - there are a lot of different parts to a complete application stack. For example, many (perhaps even most) people use Meteor purely to drive their UI. Their actual backend services are built with something totally different, and MongoDB only exists as a cache for their data so that they can deliver it to the client using Meteor.
In this case, the “backend” that you want decoupled is something totally different. And Meteor itself exists only to drive the UI, so it naturally makes sense to couple it. (I believe people are calling this BFF—“Backend for Frontend” now)
On the other hand if Meteor is the canonical source of data and is the main place where things are stored, then I agree it makes sense to keep that decoupled from the UI.
This is a simplistic understanding of isomorphism. There’s isomorphisms in the broader stack between server/database, client/editor, client/testrunner, hardware/client, hardware/server, etc. These isomorphisms are explicitly what makes Meteor productive. Because people don’t have to learn a separate API for each part of the stack.
Getting rid of isomorphisms seems like it’s racing towards the bottom. It’s certainly not in keeping with the vision of creating the .Net of Javascript.
There is no reason to argue on this much. There are different perspectives.
We think this is how it should work and will be and that’s why add something like that in Mantra.
It’s totally a client side architecture and know nothing about the server.
SSR is a special case and we have some packages run on both client and server. (FlowRouter and React Mounter).
I consider isomorphic methods bad for newcomers. They don’t get that the code will be available for the client and potentially can put sensitive data there.
Another thing that bothers me is the project architecture. You are not always sure which method is isomorphic or not.
For me, I would use them only as an optimization and we now what premature optimization is.
I strongly disagree that isomorphism with methods is hard to grasp. 80% of the time I write my methods as if they’re server side code. Isn’t this true for you?
What kind of sensitive data do you mean? Database structure? Validation?
Business logic of any type that I don’t want to expose and I consider them the value of my app.
Tokens, hashes, secrets.
Validation is true if I miss a rule and give direct access to any server component that I shouldn’t.
These are all mistakes made by people and can be avoided, specially if you are a senior. But it keeps being human mistakes that I try to avoid. That’s why I like the optimization approach. It will be something I will do explicitly and know the gaps I can be in.
I want to be sure to avoid that 20% compromising all the 80%. That 20% can be painful if is broken.
Also worth mentioning what kind of app are you build? Your startup landing page that people can only subscribe to things and so on? Go then, write your isomorphic logic. Are you building a criptocurrency ultrabot with lots of sensitive logic? Hmmm no, thank you.
But you stated that isomorphic methods are bad for newcomers. What developer tries to write a criptocurrency ultrabot with lots of sensitive logic without extensive knowledge of his tools?
I’ll try to explain this more clearly for you 
most of the methods I write for my collections benefit from client-side simulation through isomorphism. These are the 80% I talked about.
The other 20% of cases (I regret describing these habits with percentage) are situations where I want to use methods exclusively on the client or the server.
It is incredibly easy to move files, methods or even collections from server, maybe to client, and maybe to both (as outside of /client and /server) - simply because Meteor is cleverly built to have shared API’s for this stuff no matter what part of the environment you need your collection in. With the work put into having shared API’s between the client and the server, it would almost seem absurd to not reap the obvious benefits, which include client-side simulation (or optimistic UI) for methods. 
and even if you do, how hard can it be to just move methods with sensitive logic into the server folder