Yupi Emulator [C# 6/NHibernate/Post-Shuffle]

Quote:

---

Originally Posted by ovflowd

Thanks for the nice tip! @Francis Joseph. I will create now an Issue in the Repository to debate about this.
Can you explain a little bitter about what is "Orleans"?

Also what you think about the RESTapi?

Also if we're talking about scaling and redistribution we can use Cassandra for Database and Apache Hadoop.

---

It's an interesting concept but there are pre-existing patterns available purposely designed for scaled service distribution!

Laravel sounds good, I'm still very new to it however Lumen also looks great as a micro framework! :cool:

Answering @NoBrain
1. I meant "PhalconPHP OR Laravel"
2. Hum.. As i said no one will have access to the Database. The Server is the endpoint of the Data. Only NHibernate will control it. This is good in terms of security, since all type of Queries and Database Changes will pass by the NHibernate. Also a Database Backup module will be implemented in Yupi. I think an API communication complicate more the process but is good for Applications. We can say about GitHub Api, a good example to handle Applications.
Also using this pattern, we can say that Users doesn't need anymore reenter in the Hotel to see their data updated. Since Control Modules of RESTapi will take care of updating the data in execution time.
Also the API will have a Log System, "Audit System", this is good to know what is happening in the Emulator. And who is doing what.
Also only the Emulator will know the Database Access. It's more security layer. Obviously if someone get the Application Token will not be able to do XSS attacks through the API, since the API is trusted only for an IP Address. Each Token works for an Endpoint.
3. doesn't was me that choice Bootrstrap, i prefer Foundation 6

Thanks for your opinion.

- - - Updated - - -

Quote:

---

Originally Posted by CodeDragon

It means that the current text you wrote in your previous post is confusing me. You're claiming that Laravel was made by PhalconPHP. I guess it are just typos. Please consider clarifying a few things.

I'm sure you mean you do not want the users to directly interact with the database. In the post you wrote that there is no connection between the web and database. However I don't really recommend it unless you are going to use a front-end framework. Using the API will slow things a lot down it's okay if you want to use it for authentication but for the rest it's overkill. It's a nice idea but the overhead and the latency will be to much.

Correct me if I'm wrong. It's really confusing at the moment.

---

That was the point of @Francis Joseph, we can have a good scale and replication, giving all the API work for Workers/Jobs that can be replicated locally or regionally. It's a hard concept, but thinking as CDN, or better, as a self-scalable/replicable environment, that will no impact the In-Game. But yes, in terms of sockets, we will have the API requests + Client connections. But if coded in a good way, this will not impact so hard in the Emulator.

- - - Updated - - -

Observation: @CodeDragon i updated the comment changing "of" to "or"

Quote:

---

Originally Posted by ovflowd

Answering @NoBrain
1. I meant "PhalconPHP OR Laravel"
2. Hum.. As i said no one will have access to the Database. The Server is the endpoint of the Data. Only NHibernate will control it. This is good in terms of security, since all type of Queries and Database Changes will pass by the NHibernate. Also a Database Backup module will be implemented in Yupi. I think an API communication complicate more the process but is good for Applications. We can say about GitHub Api, a good example to handle Applications.
Also using this pattern, we can say that Users doesn't need anymore reenter in the Hotel to see their data updated. Since Control Modules of RESTapi will take care of updating the data in execution time.
Also the API will have a Log System, "Audit System", this is good to know what is happening in the Emulator. And who is doing what.
Also only the Emulator will know the Database Access. It's more security layer. Obviously if someone get the Application Token will not be able to do XSS attacks through the API, since the API is trusted only for an IP Address. Each Token works for an Endpoint.
3. doesn't was me that choice Bootrstrap, i prefer Foundation 6

Thanks for your opinion.

- - - Updated - - -



That was the point of @Francis Joseph, we can have a good scale and replication, giving all the API work for Workers/Jobs that can be replicated locally or regionally. It's a hard concept, but thinking as CDN, or better, as a self-scalable/replicable environment, that will no impact the In-Game. But yes, in terms of sockets, we will have the API requests + Client connections. But if coded in a good way, this will not impact so hard in the Emulator.

- - - Updated - - -

Observation: @CodeDragon i updated the comment changing "of" to "or"

---

Considering you're using Laravel, which is used in enterprise applications by A LOT of companies, the security point you made is irrelevant. Laravel automatically filters queries, provides protection against a range of attacks and is generally excellent all around (in terms of security). It's very very difficult to exploit unless the developer is an idiot or if you do raw queries.

Quote:

---

Originally Posted by ovflowd

That was the point of @Francis Joseph, we can have a good scale and replication, giving all the API work for Workers/Jobs that can be replicated locally or regionally. It's a hard concept, but thinking as CDN, or better, as a self-scalable/replicable environment, that will no impact the In-Game. But yes, in terms of sockets, we will have the API requests + Client connections. But if coded in a good way, this will not impact so hard in the Emulator.

---

Why don't you just set-up the permissions in the database itself by using an installer that sets them up correctly? This might become an issue on a shared hosting but I assume no one is going to use a shared webhosting to host their cms.

As for database replication this also exists in almost all SQL servers. You really don't need to make it super complex. Just go with the bare bones by protecting the tables with permissions. That's a lot easier and faster to configure then writing a whole API.

Good point @NoBrain, i never used frameworks such Laravel or Phalcon, a friend of mine that works at Google, said Phalcon is great.
In all my works i use specific frameworks coded by me for the specific thing. I don't like a lot Frameworks, i prefer using some libraries and my code.
But the question isn't only about Queries, but is about providing a Full API.
@CodeDragon, again other good point. Making API compatible will be more complex, but why not just use the API? I think is good. Also the Database Modeling is changing rapidly, we using a tool of NHibernate that allows Database Upgrade. But we really want all data being managed by an unique module.

Quote:

---

Originally Posted by ovflowd

@CodeDragon, again other good point. Making API compatible will be more complex, but why not just use the API? I think is good. Also the Database Modeling is changing rapidly, we using a tool of NHibernate that allows Database Upgrade. But we really want all data being managed by an unique module.

---

It's up to you on how you implement it. I would stick with the easiest solution since APIs tend to become very complex if you are going to start changing things around. Just give it some thought before you shoot your own foot off. I'm just making suggestions.

Quote:

---

Originally Posted by CodeDragon

It's up to you on how you implement it. I would stick with the easiest solution since APIs tend to become very complex if you are going to start changing things around. Just give it some thought before you shoot your own foot off. I'm just making suggestions.

---

I think you're wrong (maybe i'be wrong) but the goodness of the API it's that it will not change, since only what changes it's in Backend.
The API will be the same, and only the backend will change. Obviously with major changes the API will change. But better change only one line command, than a lot of queries and PHP code.

Quote:

---

Originally Posted by ovflowd

the goodness of the API it's that it will not change

---

This is wrong. APIs will change as you add more features to your CMS that would then depend on a new API call or a modified API call. One day you might even realize your entire API scheme is shit and you redo everything.

Also, I'm with @CodeDragon on this one. Coupling the API together with the gameserver is a very bad idea as the gameserver becomes a single point of failure which is very likely to suddenly just crash. A better idea would be to either have a separate API from the gameserver or have a direct connection towards the database as CodeDragon suggests. You can achieve most of the security benefits you get from encapsulating the database in an API by using access rights/privileges in the database.

Also, let me correct you that the API on the gameserver is not RESTfull as the gameserver itself is as stateless as you can get :^)

Quote:

---

Originally Posted by maritnmine

This is wrong. APIs will change as you add more features to your CMS that would then depend on a new API call or a modified API call. One day you might even realize your entire API scheme is shit and you redo everything.

Also, I'm with @CodeDragon on this one. Coupling the API together with the gameserver is a very bad idea as the gameserver becomes a single point of failure which is very likely to suddenly just crash. A better idea would be to either have a separate API from the gameserver or have a direct connection towards the database as CodeDragon suggests. You can achieve most of the security benefits you get from encapsulating the database in an API by using access rights/privileges in the database.

Also, let me correct you that the API on the gameserver is not RESTfull as the gameserver itself is as stateless as you can get :^)

---

Yes i agree in part with you. Maybe the API need be placed in somewhere else. But i continue thinking that API will be nice. But yes is harder.

Quote:

---

Originally Posted by ovflowd

But i continue thinking that API will be nice. But yes is harder.

---

In that case, make the model code a separate library you can re-use in your API module.

Quote:

---

Originally Posted by maritnmine

In that case, make the model code a separate library you can re-use in your API module.

---

Yupi is actually made in this way. We have separated modules working as Service.
We Have Yupi.Main.exe that call all modules, but actually have also Yupi.Rest.exe and Yupi.Model.exe

Quote:

---

Originally Posted by ovflowd

We Have Yupi.Main.exe that call all modules, but actually have also Yupi.Rest.exe and Yupi.Model.exe

---

Can you elaborate on why you did it this way?

Quote:

---

Originally Posted by maritnmine

Can you elaborate on why you did it this way?

---

Wasn't me. Was the Main Developer (Commiter) of Yupi Felix (Thedoct0r11)

Hey guys!
I added Documentation things directly with Swagger Update.
Check now the Yupi Emulator documentation here: Swagger UI

Any "updates" on the cms made by kylon? (or did he already give up again x.x)