Mystic-AAC

[Igor Santos213]

I'm developing a website for the Tibia community called Mystic AAC!

Technologies I'm using:

• Node.js
• TypeScript
• Fastify
• Prisma ORM
• Redis (Session Management)
• EJS Templating
• MySQL Database

It's still in the early development phase, but there are already some interesting features.

Want to follow along? Check it out on GitHub: GitHub - WebCodeSmith/mystic-aac (https://github.com/WebCodeSmith/mystic-aac)

Discord: Participe do servidor do Discord MysticAAC! (https://discord.gg/PcxCdKS)

 

[rashid07]

link off

 

[Itutorial]

Is there a reason you want to hurt yourself by using TS?

 

[Pedrook]

Is there a reason you want to hurt yourself by using TS?

why hurt?

 

[Itutorial]

why hurt?

Well, for one it is one person working on the code I am pretty sure so typescript is pretty much useless off the bat. Then, there is all the required code for everything you want to do to feel like you are safer when you really aren't. You are safe from making obvious mistakes you shouldn't make anyway. Then you have to deal with ts compiler and the end result of the code is also really bad. I don't see any reason to use anything but standard JavaScript. Even using React (which I am doing on my servers website) isn't needed for a standard AAC. It just slows everything down and gums up the works. Which he is also using a bunch of other libraries as well. You can create an amazing website now with basic HTML, CSS, and JavaScript. Does that answer your question lol?

 

[Pedrook]

Well, for one it is one person working on the code I am pretty sure so typescript is pretty much useless off the bat. Then, there is all the required code for everything you want to do to feel like you are safer when you really aren't. You are safe from making obvious mistakes you shouldn't make anyway. Then you have to deal with ts compiler and the end result of the code is also really bad. I don't see any reason to use anything but standard JavaScript. Even using React (which I am doing on my servers website) isn't needed for a standard AAC. It just slows everything down and gums up the works. Which he is also using a bunch of other libraries as well. You can create an amazing website now with basic HTML, CSS, and JavaScript. Does that answer your question lol?

I understand your point about keeping things simple, but I disagree on some aspects. TypeScript isn't just about avoiding obvious errors—it has smart auto-completion, inline documentation, and refactoring safety, which is very useful, even in small projects. Who hasn't changed a property in JS and only discovered the error at runtime? With TS, that doesn't happen.

About Next.js and React: yes, you can do everything with pure JS, but frameworks exist for a reason. Next.js brings efficient routing, SSR/SSG (which improves SEO and performance), and an organized structure that scales better. It may seem like overkill for a tiny project, but if your app grows, you'll be thankful you already have this in place.

As for "slowness": if used correctly, Next.js is optimized for performance (even better than many poorly designed vanilla sites). And the time saved on maintenance with TypeScript + React makes up for any initial overhead.

In the end, does pure JS work? Of course. But saying that TS and frameworks are useless ignores the benefits that thousands of developers and companies enjoy every day. If you master the tools, they speed up development, not hinder it.

EDIT: You make me wonder, is Nekiro a fool for using next, typescript on his server? lol

 

[Itutorial]

I understand your point about keeping things simple, but I disagree on some aspects. TypeScript isn't just about avoiding obvious errors—it has smart auto-completion, inline documentation, and refactoring safety, which is very useful, even in small projects. Who hasn't changed a property in JS and only discovered the error at runtime? With TS, that doesn't happen.

About Next.js and React: yes, you can do everything with pure JS, but frameworks exist for a reason. Next.js brings efficient routing, SSR/SSG (which improves SEO and performance), and an organized structure that scales better. It may seem like overkill for a tiny project, but if your app grows, you'll be thankful you already have this in place.

As for "slowness": if used correctly, Next.js is optimized for performance (even better than many poorly designed vanilla sites). And the time saved on maintenance with TypeScript + React makes up for any initial overhead.

In the end, does pure JS work? Of course. But saying that TS and frameworks are useless ignores the benefits that thousands of developers and companies enjoy every day. If you master the tools, they speed up development, not hinder it.

EDIT: You make me wonder, is Nekiro a fool for using next, typescript on his server? lol

Everything I am saying is based on the assumption it is going to be used for a basic AAC. If OP is going to add a bunch of stuff which hasn't been released in the OT community and make this the ultimate AAC than sure using some libraries may be beneficial. The issue is that will probably not happen. I just doubt this project will be big enough to need all the things he is using. I would wager he would be better off doing this as just a way to practice than making anything serious which would also mean the AAC shouldn't really be used seriously.

 

[Nekiro]

Well, for one it is one person working on the code I am pretty sure so typescript is pretty much useless off the bat. Then, there is all the required code for everything you want to do to feel like you are safer when you really aren't. You are safe from making obvious mistakes you shouldn't make anyway. Then you have to deal with ts compiler and the end result of the code is also really bad. I don't see any reason to use anything but standard JavaScript. Even using React (which I am doing on my servers website) isn't needed for a standard AAC. It just slows everything down and gums up the works. Which he is also using a bunch of other libraries as well. You can create an amazing website now with basic HTML, CSS, and JavaScript. Does that answer your question lol?

If you want to go for using vanilla js, don't use js at all. Nowadays you just don't do that. Remember the jquery on every php site frontend? Yeah, no one liked it, but there were no better things. Not to mention pure javascript is just hard to write to be maintainable, because editing this is a nightmare. React is pretty fast and allows you to do many nice things. Anyway curious why do you think all these js frameworks are slow? In the end it's all matter of how you scale it. For example for php you have great nginx that literally do all the things for you to keep the site performant. JS doesnt have a dedicated tool, you will probably end up using docker and scale it yourself.

While js is a nice to write language, hosting it without killing the site with a free flooder may be hard, but it's matter of how you host it.

Btw if you want to check for yourself if a nextjs (react framework) is slow, you can visit darkrest website.

 

[Itutorial]

If you want to go for using vanilla js, don't use js at all. Nowadays you just don't do that. Remember the jquery on every php site frontend? Yeah, no one liked it, but there were no better things. Not to mention pure javascript is just hard to write to be maintainable, because editing this is a nightmare. React is pretty fast and allows you to do many nice things. Anyway curious why do you think all these js frameworks are slow? In the end it's all matter of how you scale it. For example for php you have great nginx that literally do all the things for you to keep the site performant. JS doesnt have a dedicated tool, you will probably end up using docker and scale it yourself.

While js is a nice to write language, hosting it without killing the site with a free flooder may be hard, but it's matter of how you host it.

Btw if you want to check for yourself if a nextjs (react framework) is slow, you can visit darkrest website.

So that is kind of my point. Libraries are generally slow because of bloat and you are limited to their implementations/solutions. That doesn't mean you can't use libraries without the site being optimized just fine. That isn't really what I am getting at. If you notice the only question I was asking in the beginning is why bother using typescript. I also said I am currently using React on my site so obviously I am not against the use of frameworks or libraries.

What I am saying is OP is using a lot of different tools in this AAC which may just end up being redundant. It could be a better solution to modify what he is using or just not use some of the tools. That will all depend on what he is going to put into the AAC. For instance, I don't really understand why Redis or a ORM would be needed for a basic AAC. It's all a matter of opinion but you could easily do without both of those and create a faster/easier solution. The cost being time and possibly security. I take into account the security included with these frameworks.

TL;DR I am not saying using frameworks/libraries = slow website. Nextjs is actually really fast when properly optimized. Pretty much all are but again, you can come up with better solutions. It's essentially jack of all trades vs a master of a trade type of argument and one last time I will mention my only question was why he decided to use typescript. Typescript makes the code base much harder to work with and have people contribute to/work on their own stuff. If you notice I didn't ask why he is using fastify haha.

 

[Pedrook]

So that is kind of my point. Libraries are generally slow because of bloat and you are limited to their implementations/solutions. That doesn't mean you can't use libraries without the site being optimized just fine. That isn't really what I am getting at. If you notice the only question I was asking in the beginning is why bother using typescript. I also said I am currently using React on my site so obviously I am not against the use of frameworks or libraries.

What I am saying is OP is using a lot of different tools in this AAC which may just end up being redundant. It could be a better solution to modify what he is using or just not use some of the tools. That will all depend on what he is going to put into the AAC. For instance, I don't really understand why Redis or a ORM would be needed for a basic AAC. It's all a matter of opinion but you could easily do without both of those and create a faster/easier solution. The cost being time and possibly security. I take into account the security included with these frameworks.

TL;DR I am not saying using frameworks/libraries = slow website. Nextjs is actually really fast when properly optimized. Pretty much all are but again, you can come up with better solutions. It's essentially jack of all trades vs a master of a trade type of argument and one last time I will mention my only question was why he decided to use typescript. Typescript makes the code base much harder to work with and have people contribute to/work on their own stuff. If you notice I didn't ask why he is using fastify haha.

Ah, now I understand your point better! You are not against frameworks/libraries per se, but you question whether all of the OP's choices are necessary for an AAC – especially TypeScript, Redis and Prisma.

I agree that Redis may be overkill if it is only for sessions (a stateless JWT or session in MySQL would do the trick), but if he plans features like rankings cache, real-time leaderboards or websockets, then it makes sense. Prisma (ORM) also seems overkill for a simple AAC, but if the project grows (e.g.: support for multiple databases or complex queries), it saves time.

Regarding TypeScript, I disagree that it hinders contributions. On the contrary:
It helps onboarding (autocomplete + types show what each function expects);
It reduces bugs in PRs (e.g.: someone tries to pass string where it should be number);
The TS/Node community is already huge (many devs prefer typed projects).
Of course, if AAC is just a registration + login panel, TS really is "killing ants with a bazooka". But if the OP wants something modular (e.g.: plugins, customizable systems), typing helps to keep the code predictable.
In the end, his stack seems to aim for scalability (not just AAC, but a base for other projects). Is it over-engineering? It depends on what he's going to build. If it's just a Gesior clone, yes. If it's a "TibiaCMS" with an integrated store, REST API, etc., then it makes sense.

(And I admit: Fastify is great, but for AAC I would still use Express + EJS for simplicity haha.)

If we were to list everything that is 'unnecessary' in OTs, we should go back to using TFS 0.3.7. Sometimes the stack is about the pleasure of building with modern tools, not just necessity.

 

[Nekiro]

Ah, now I understand your point better! You are not against frameworks/libraries per se, but you question whether all of the OP's choices are necessary for an AAC – especially TypeScript, Redis and Prisma.

I agree that Redis may be overkill if it is only for sessions (a stateless JWT or session in MySQL would do the trick), but if he plans features like rankings cache, real-time leaderboards or websockets, then it makes sense. Prisma (ORM) also seems overkill for a simple AAC, but if the project grows (e.g.: support for multiple databases or complex queries), it saves time.

Regarding TypeScript, I disagree that it hinders contributions. On the contrary:
It helps onboarding (autocomplete + types show what each function expects);
It reduces bugs in PRs (e.g.: someone tries to pass string where it should be number);
The TS/Node community is already huge (many devs prefer typed projects).
Of course, if AAC is just a registration + login panel, TS really is "killing ants with a bazooka". But if the OP wants something modular (e.g.: plugins, customizable systems), typing helps to keep the code predictable.
In the end, his stack seems to aim for scalability (not just AAC, but a base for other projects). Is it over-engineering? It depends on what he's going to build. If it's just a Gesior clone, yes. If it's a "TibiaCMS" with an integrated store, REST API, etc., then it makes sense.

(And I admit: Fastify is great, but for AAC I would still use Express + EJS for simplicity haha.)

If we were to list everything that is 'unnecessary' in OTs, we should go back to using TFS 0.3.7. Sometimes the stack is about the pleasure of building with modern tools, not just necessity.

I use all of them except prisma, because I use drizzle orm for database handling. Redis is super nice for session storing and other non crucial things like or example linking codes (confirmation for example) to certain emails, you have ttl which makes it even better, because it will auto clean up itself also caching is a big thing to have on www and redis is just perfect for that. About the project while I didnt look what the op use, the things mentioned seem like a basic stack to write maintainable CRUD application. I honestly can't think of writing javascript without typescript nowadays, types (in any language) just makes the development so much easier and better.

and honestly I wouldnt say AAC is a simple website, it after all has LOTS of logic to write, lost account, register, login, house auctions, highscores etc etc if you aren't mindlessly querying database for everything it may get complicated