- SSR with React and Meteor in a simple working starter project example
- Ability to have a view instead of pub/sub being the default way of sending data to the client. In the case of a homepage view of data which doesn’t require pub/sub and is just static but database backed (currently had to roll my own to achieve this simple funcionality)
- Native support for MySQL (mongodb is great but doesn’t perform as well as MySQL specifically the percona build)
- Offline support built into core (groundb)
- Memcache support built into core
- JSON Rest API token auth built into web app and part of core so creating an API doesn’t require any packages and is part of meteor’s base
- Rollback CFS file upload module to the non foobar’d original that still works (new version is DOA, broken examples totally briked with no support.)
Meteor users collection with ObjectID suport in _id, no more Strings.
1 Like
Right now my pain points are:
- ESM packages
- Testing, code coverage, etc. (yes, there are solutions, but it is not straightforward)
Other potential improvements I would appreciate (that are not in development):
- Official login with Apple package (so that official OAuth supports all the major players, especially since Apple OAuth is required if you want to have OAuth on iOS)
- Support for more MongoDB stuff (after MongoDB 5 update)
- More awesome stuff around accounts (discussed on GitHub)
- Private packages on Atmosphere and marketplace for paid packages
I would also look into integrating some other most used community patterns into core, but there are more important things to consider first. This is a bit difficult given Meteor’s modularity, so maybe a few reference/starter apps can be created for each front-ends with the necessary tools for each included. I’m working on one for social apps right now.
6 Likes
Hi, this the list of features that I would like to see them implemented on Meteor:
- Upload files as form-data over DDP
- Backward compatibility of Vue 3 Integration with Vue 2 Integration (I’m very excited to use it when Vuetify 3 is released the next month!
)
- Make possible to subscribe to publications like in Vue 2.
- Transactions support for Accounts methods like createUser, sendEnrollmentEmail, sendVerificationEmail, etc. Mentioned here.
- Node 16 and MongoDB 5
- Official support for code coverage in meteor test
Things that I’d change about Meteor
- Currently, the
Meteor.callfunctions receives as parameter a callback to get the response of the meteor method, however, some co-workers and I think that would be nice to invoke that function by usingawaitstatements, for instance:
async saveUser(userData){
const response = await Meteor.call('user.save', userData);
//Do more things with clean code (avoid callback hell), either async or sync tasks
}
The purpose of using async/await is to keep a clean code and avoid the callback hell. Currently, we are using a wrapper for Meteor.call, however, it’d be nice to include this in the core of Meteor.
- Another thing that I’d change is how to subscribes 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 to invoke publications with 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 a very good framework to build web apps (actually APIs) based on REST. It’s 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 copy things from other frameworks like Nest. I know that Meteor is an isomorphic framework, so, I guess that is the reason because it can have different layout structures but maybe it’s better to have a standard structure which allows to new meteor devs 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 an standard directory structure
- I use Meteor with Vue in the same project because Meteor allows to have both directory structures, for back-end and front-end in the same app. So, the standard directory structure which I mean, it’s specially 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 productsand 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 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.
- 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
- Use NPM as Meteor’s only package manager.
- When I started to learn Meteor, I was wondering 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 their 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 use 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 an impossible change, because it would mean to migrate 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.
I have already some projects created which bring some of the things mentioned above. So, they’re the following:
Scaffold Meteor Vue (Complete version)
Scaffold Meteor React (Still in progress)
It’s worth mentioning that I have already some apps in production with some of these things, and I have been improving the scaffold when start a new project.
3 Likes
Backward compatibility of Vue 3 Integration with Vue 2 Integration (I’m very excited to use it when Vuetify 3 is released the next month!
)
Regarding this point, I believe Meteor should sponsor Akryum. As Meteor takes special care of the React integration, Vue should be no different and they already sponsored @zodern and @storyteller for some work.
8 Likes