Running Rocket.Chat server-side only code

[markb-trustifi]

Hi all.

I’m new to the Rocket.Chat, but as far as I understand the main “Rocket.Chat” repository, it contains both the client-side and the server-side code.
Is it possible to separate those and to have a repository with the server-side only API or GraphQL, without integration plugins and everything related to the rendering admin and client side HMTL?

It should be something similar to what the @rodrigo.nascimento proposed in his post:

Moving away from Meteor and beyond

This idea is old, but we really need to go to this path. We already started this movement with the merging of the Globals Removal and the eminent merge of the Depackaging Pull Request, but it isn’t enough for our goal of having the server side running as a micro-service architecture. Globals Removal It was the first step, remove everything that was shared among packages and the main code and convert them to imports, only then we could start having the benefits of the import, start structuring…

How can I strip everything unrelated to the server-side?
Delete all “client” folders? Maybe there is some more elegant solution?

[rodrigo.nascimento]

Today it is not an easy thing to do, you would need to delete many files and remove the import references, even so Meteor will keep a empty UI.

May I ask why you want this?

[markb-trustifi]

The Rocket.Chat application is too heavy and cannot be built in Heroku because it has limits for both build time and dependencies size. The “Build with Heroku” button actually doesn’t work.

[zdelfw]

It looks like you can do a meteor build (and thus a docker build) of the server side only according to this post.

[aaron.ogle]

I would also say you could configure your nginx or proxy of choice to only allow traffic through to /websocket and /api

[sing.li]

Are you referring to building with the “free tier” Heroku dyno?

[markb-trustifi]

Yes.
Do you think that if we update the dyno, it could work?

[sing.li]

if you’re building during deploy (kinda the heroku “problem”) - you’ll need to upgrade the dyno to mega$$ 8GB of memory for initial deploy … afterwards it can be ok with 2GB (or even less)