Seeking Community Input: Meteor.js Roadmap

announce
61
  • Testing with modern testing tools (Jest, Playwright, React Testing libraries, etc.)
  • Move off of Atmosphere (or open source it)
3 Likes
62

Something popped up in my mind few days ago, but if Meteor Software is still intent on bringing redis-oplog to the core, @diaconutheodor expressed intent in helping out at this endeavor so try reaching out again and see if is still interested. There’s no one better to work on this integration since the guy who built it!

4 Likes
63

Backwards compatibility or migration for existing packages does sound nice, but it’s an aspect that could be time consuming and there are a number of packages presumably relying on ecmascript by now too, so it will be difficult.

I think at least a fork not focused on back compat (at least initially) would allow a group of people to spend time on the important future-forward ideas. Then this fork can help inform what Meteor actually needs to do while keeping back compat, or perhaps the back compat can be bolted on after the new concepts are in place.

Of course not having a community be able to move forward could be a bad thing. At the same time, if the new thing is really good, it’ll find the community regardless of back compat or not (f.e. just like new things like Astro have).

This will be a free time effort for me if I do find time (unless I can get hired, I’m available for part time at the moment) so with that in mind I would personally want to do this exploration without back compat taking away time from implementing the concepts.

On another note, I think Meteor needs its own Showcase to really really sell itself:

1 Like
64

Yeaaaaaah, really can’t wait to get rid of Fibers. I’m now getting this error in an app with innocent normal async/await code:

AssertionError [ERR_ASSERTION] [ERR_ASSERTION]: Cannot await without a Fiber

I didn’t want to troubleshoot, so I reverted back to Meteor.bindEnvironment (but this means I’ve made work for myself when the Meteor update that removes Fibers lands).

65

That looks like the correct error :sweat_smile:

1 Like
66

That’s a Meteor error. Vanilla Node.js doesn’t have this issue.

I simply tried to use a Promise (returned from Meteor) like you would in plain Node.js, but it fails.

This just gets in the way of writing modern code like with any non-Meteor Node.js app.

67

Yep. We are all awaiting here with the Promise of Meteor 3.0

68

Hi, I remember someone published a similar topic in the past, so my list was this one Question for Meteor Developers - #27 by diavrank95 . However, some of the items have already been resolved in the last few months, so, I’ll leave here only the missing ones and I will add a few ones:

  • Upload files as form-data over DDP
  • Transactions support for Accounts methods like createUser, sendEnrollmentEmail, sendVerificationEmail, etc. Mentioned here.
  • Official support for code coverage in meteor test (not sure if there is already an official package for code coverage)

Things that I’d change about Meteor

  • One thing that I’d change is how to subscribe to publications since currently, you need three things in the client side to invoke a publication: publication name, parameters, and the collection which is used to return the cursor of the publication. So, I’d like that publications only receive the publication name and its parameters, without specifying the collection. So, I imagine invoking publications in this new way:
//Client side
const subscription = Meteor.subscribe('users.list', params);
const reactiveData = subscription.findData(selector, options);//or just use: subscription.reactive() if no longer possible to use parameters with this new change.

I don’t know if this change is possible, but this would fix an issue that maybe many beginners have had when they are learning to use publications, which is the combination of data when 2 publications use the same collection and they’re invoked by the same client at the same time.

Features for Meteor 3.0+

I have been working in my current job with Nest JS and I can say this is a very good framework for building web apps (actually APIs) based on REST. It is very similar in some way to Spring Boot and Laravel frameworks because have a well-defined directory structure and entities which allow to developers follow the same pattern to build apps. So, in Meteor we have in the documentation an example directory layout but it could be much better if it copies things from other frameworks like Nest. I know that Meteor is an isomorphic framework, so, I guess that is the reason why it can have different directory structures but maybe it’s better to have a standard structure that allows new Meteor devs to have a concrete shape of Meteor framework to build apps and at the same time in an even faster way.

So, this is a list of features that Meteor can copy from other frameworks:

  • Have a standard directory structure
    • I use Meteor with Vue in the same project because Meteor allows to have both directory structures, for the back-end and front-end in the same app. So, the standard directory structure which I mean, it’s especially for the backend which it should include folders to store files like middlewares, controllers, publications, services, dtos, models, helpers, constants, etc.
  • Create some commands for meteor-tool to create file templates (for back-end only). For instance: meteor make:controller products and a file is created with the validated method. So far, I have in mind commands to create controllers (validated methods), publications, services (business logic), and models (data layer). Also, it will be needed a flag to create a meteor app with the standard layout. For example: meteor create myapp --standard
  • Use Typescript as the programming language for standard meteor apps.
    • Nowadays, it’s well-known that many companies are using TypeScript instead of pure JavaScript, since you can avoid bugs by using data types and this helps to build scalable big applications.
  • Include Astronomy for standard meteor apps.
    • Nowadays, all web frameworks use an ORM (Object Relational Mapping) for the data layer. Just to mention a few examples: NestJS uses TypeORM, Laravel uses Eloquent and Spring Boot uses Spring Data (based on Hibernate). Although Meteor uses a NoSQL database with MongoDB (which has primary support), its ODM (Object Document Mapping) is Astronomy since AFAIK is the only one created for Meteor and it works very well. The only thing it needs is to add transactions support in the main repository, but I have done a fork and I published a new version of this package in Atmosphere , however, it will need its typings of TS with this new version since the original typings only work with original meteor package which is jagi:astronomy. So, in short, it would be nice to add support for an ODM of Meteor, either Astronomy or a new one created by Meteor Software.
  • Use NPM as Meteor’s only package manager.
    • When I started to learn Meteor, I wondered what was the reason that Meteor didn’t use NPM as its package manager and I found that it was because Meteor was released when NPM was in its first versions, so, maybe MDG wanted to create its own package manager because NPM was not as developed at that time. Nowadays, npmjs is the platform with the largest number of packages (more than maven, composer, pip, among others), so, I think if Meteor uses NPM as its only package manager, more benefits will come, for example: more nodejs/javascript developers could contribute to Meteor by creating only npm packages because it would no longer be working on a single Meteor ecosystem, but rather it would be using possibly packages that use other Node frameworks (such as Nest, Express, Electron, React Native, etc.). Also, another benefit it would be that deployments of meteor apps would be faster with an implementation of other NPM modules which are used by other frameworks like Express or Nest. Maybe this is a difficult change because it would mean migrating all meteor packages to NPM, but if we start to standardize meteor applications, we can identify the packages that would be worth migrating to NPM.

Lastly, I think the API for Meteor Methods can be improved by using OOP paradigm (by using classes and inheritance at each layer. e.g. controllers, services, models, dtos, etc) and decorators from TS.

@Controller('users') // in this part we could specify the prefix for all the method names defined in this controller. e.g. users.create, users.update, users.delete OR /users/create, /users/update 
export class UsersController extends Method {

   //...maybe it will be needed a class constructor to inject the services that we want to use in the controller.  

   @Name('users.create')// or like a route '/users/save'
   @Validate(CreateUserRequestDto) // Request DTO is a class that has the structure of the endpoint's parameter. In this kind of DTOs we can take advantage of the `Match` package to validate the parameters.
   @ResponseDto(UserCreatedResponseDto) // Response DTO is a class that has the structure of the endpoint's response
   @BeforeHooks(functionX, functionY)
   @AfterHooks(functionZ)
   createUser(user: CreateUserRequestDto){
       return this.usersService.createUser(user); // Returns a user object which will be used in the Response DTO to take the properties that are needed to return to the client.
   }

  //more meteor methods ...

}

The above approach would be a proposal to implement an N-Layer Architecture for standard apps in Meteor.

69

That might be possible for a high-level API. Not sure if this is possible in general because publications can return one cursor, multiple cursors, or a handle. See Publish and subscribe | Meteor API Docs.

I must say I would only give this as a recommendation, and maybe part of a scaffold tool. But I definitely do not want this structure, libraries or tools to be imposed on me.

Yes.

Yes!

I’ve always been limited by what Meteor’s API had to offer in terms of publications and methods. A lot of people use additional packages to fill the gap, some use ad-hoc libraries. I would say that it would be nice to have a native API which includes validation etc. but it would perhaps be more interesting to first have low-level public APIs to allow us to roll our own more easily when we need it.

2 Likes