Technology advice for mobile application - node.js

I would like to develop a mobile game, kind of like an interactive ARG.
The players would see POI-s on a map, and they can interact with them in various ways. Some interactions on a POI should be visible to other players real time, and players should receive push notifications when a new POI appears in their area.
Up until now, I mostly worked with web technologies, so I figured a Node.js for backend, and a React Native for the application would be nice choices and I could learn both along the way. Since I have little experience with both, and don't really know about their capabilities performance-wise.
Are these technologies a good choice for an application like this? Is there a reason to go full native iOS/Android instead of React Native?
Could Node.js and React Native handle like 1-200k players daily? (It will probably never get there, lol)
I know it's just a pet project, but I'm interested in what would be the "industry standard" stack for something like this?

I would think using React native should be fine for this genre of game for your frontend/client. Where it seem to involves a lot of point click, drag and drop, present player with information. If more real time rendering and interactivity then you may need to use a library/framework that are suitable for more real time rendering and interactivity.
As for the backend using Node.js is fine for handling your data requests. For scaling to support lots of user, then that's quite a big topic that you'll need to work out. You'll typically have to look at how complex your data/requests are and so how much your server can handle the load. From there you will need to load balance on multiple servers.
For game or any type of application, where you need a backend it's very similar in needs. You'll use a language that's best for backend development and performance. From there you have to serve it and scale accordingly base on your loads. You can leverage AWS or other cloud providers to do a lot of these.
Hopefully this answer some of the things you're asking for.

Related

Node Project & Practice

I am learning Node JS. It had almost learnt 70%. I am very interested in Backend Development but I'm not interested in Frontend development. My question is how do I practice my Node Skills. I only know HTML, CSS in Frontend. How can I make projects in Node JS without knowing Frontend? Or do I need to learn frontend frameworks such as React too to make projects.
You can build an API and use postman to make requests. Start with something simple and keep improving by refactoring your code.
You can work on the API creation part but in my opinion, you must learn one frontend framework it will not only increase your skill sets but also help you to coordinate with frontend easily and take more advantage of it than the projects you will build will be more useful and advanced as well.
You could also focus on implementing some algorithms and data structures starting of with simple ones such as LinkedLists, ArrayLists, sorting algorithms and then move on to (binary) trees and graphs.
These will be required for any programming language to solve (complex) problems and there are many books and internet resources for this. Just search for algorithms and data structures and you'll get plenty. You don't need more than a console application with some simple console.log() statements to implement algorithms - no need for fancy UI.
Last but not least, you should certainly have a look at TypeScript if you want to develop more complex backend applications.
If you really want to do Web Development though it is certainly helpful to have a basic understanding of frontend development or know the basics of common frameworks such as React, Vue, Angular or Svelte.
As others have mentioned for API development you could also just use Postman to send requests.

If I'm integrating two seperate API's, is a MERN stack appropriate?

I have two separate cloud-based APIs that I am working on integrating together. Neither software directly talks to each other so I am creating something in the middle to get them to communicate. I have had trouble finding examples or documentation on how exactly to do this, does anyone know of any resources that could help me out?
My plan going in was to use a MERN Stack, running on a local server to do GET and POST requests to both APIs, use some mapping and logic to transpose the data into the correct format and send it to the other software. I do not have a client per se (other than myself) on my end, so I really will be skipping the React part of MERN, at least that is what I'm thinking. I'll be using Mongo to keep track of both sets of data for redundancy. I also considered using a LAMP Stack but felt that MERN would be faster in handling the data, and Mongo is more flexible in handling different data formats. If there is another process or technology that could help me that I'm not thinking of, I would be grateful to hear about it.
Has anyone encountered something like this before? Thank you.
As with most architecture questions, there's no completely right or wrong answer here. You could certainly design a well-built system to handle for this purpose with either stack; even more-so when you mention that your front-end framework is not an important consideration. Instead, ask yourself questions like this:
Which stack do you have more experience with, and is this an appropriate time to learn a new set of technologies, or is it important to do the best work you're capable of right now (how important is time, cost, or quality in this case)?
Another generalization I'll stick my neck out for is a data-first approach; what sort of data are you dealing with from each cloud integration, and what kind of data do you need to support and/or create in order to make your system work? Mongo, being a NoSQL persistence layer, will allow you to change your data model and handle more varied data in a quicker and easier manner than a SQL solution will. This is a double-edged sword, however, as lack of validation and a strongly-constrained (typed?) data model will make your application harder to work with and debug as it grows. In short - how big might this application grow?
If you have a handy and familiar way to manage the three different data models you're dealing with (cloud service 1, cloud service 2, and your app) via MySQL, then that's a compelling reason to use it. However, if your style is to start dumping data into your database and you're comfortable with a more iterative approach (which may require more, albeit shorter rounds of refactoring), then Mongo with MERN may be the preferable choice.
Finally, will others ever be working on this application? If so, which language would you prefer to be dealing with them upon - PHP or Javascript?

Vanilla Node vs Express

I'm wondering if some of you veterans could provide some guidance to some of us noobs.
Is there any advantage to writing vanilla Node over using Express? More specifically, any particular scenario where using Express will not be an option? And lastly for the tasks that you can use Express for, how deep should you go within the layers of abstraction to find out what's going on?
I mean there are plenty of people who can create robust and powerful web applications and they have no clue what the hell Express is actually doing for them.
Much appreciated
If I were you, I'd use express.
To be honest, Express isn't much of a web framework. It's really barebones, and barely adds any functionality on top of Node core.
With this said, however, there are some benefits:
For better or worse, express has become the 'defacto' default web framework for Node developers. There's a lot of information about it.
Express provides some core things that are useful: a routing layer (to map functions to URLs), an 'application' object that you can bind variables to for settings, etc. -- and a simple middleware model that lets you add functionality to your app easily.
Because express is so close to 'barebones' node, you can still write raw node code to work with it. It isn't at all complicated like other 'larger' frameworks: django, rails, etc.
There are a TON of third-party express middlewares you can use which add all sorts of functionality to your site. This makes building your site easier.
Finally -- the biggest reason to use express is that it does almost nothing. It isn't significantly different from using raw node except that it provides some simple abstractions over lower level stuff.
Because express is so simple, it means you don't need to learn much to use it, and can write your app in whatever way you want (it doesn't enforce any sort of patterns).
I'd like to add a few things here that might help you out. One thing that I have come to realize with software engineering is that there is never a "catch all" answer to a lot of these types of questions. Since each application is different, it is a good idea to look at the challenges and figure out what is the best tool for the job.
If you look at some of the performance tests done on the frameworks you notice that vanilla node is ultra performant. But most of the time your application isn't going to need to handle 8000 requests per second, and even if it does you can always scale your server horizontally nowadays. So you trade off a little bit of speed to gain a few benefits, such as:
Much easier to write.
The code base, in my opinion, is much easier to maintain.
A lot of the little gotchas are taken care of by the framework so you don't have to be a Node.js god.
Middleware.
Now, that doesn't mean that every single application should use express. A lot do because it is about as barebones as it gets. For instance, Walmart created Hapi because they claim that it is easier to maintain their code base with a 'configuration first' approach. So maybe if you are going to have this monster backend and a monster team, Hapi might be a good choice. If implementing something with real-time you might want to use something like socketcluster.io to help you scale websockets. It is all about picking the right tool for the right job.
That being said, there are advantages to building a server with vanilla Node, especially when learning to develop node apps. Since frameworks abstract a lot of the lower level stuff it takes away the opportunity to pick up some cool node tricks here or there. Or a lot of times if a framework is insufficient or an npm package is doing something weird it is good to have that knowledge of vanilla node under your belt to really understand what is going on. Having the skill of knowing how Node.js works is such a benefit when working with any framework.

Node.js: Socket.io + Express needed for real-time apps?

I have just began working with node.js and have gotten the hang of the basics.
Right now I'm trying to see if I can create my very first real-time web application using node, during my research I have seen modules like "express.js" and "socket.io' pop up very often as frameworks used for node web apps.
My question is; do I really need to learn these two in order to make real-time production level node.js applications?
Also, what other things should I look at? I heard about tempting engines being an asset, but 'm not sure of their use.
You don't need to use any modules but you give up a lot when you don't. Express.js is a great place to start. It has good documentation and makes the whole process much easier. I use jade and stylus for my css and templates.
Socket.io is again optional but if you are doing real-time updates it sure makes things a lot simpler. Socket.io deals with all of the browser differences with one api and the client will always connect using the fastest technology.
Socket.IO is mandatory for real-time applications. If you have to implement a chat, a broker, a server status tool or something like that and other natural real app, you must consider use this Node package. If your site do not require something real-time bi-directional message handler you just avoid the usage of this tool.
In case of all application needs to be made in real-time situation, you can see a more appropriate framework to approach it, like Meteor

chat application: node.js or APE?

I want to create a chat app which would use php/codeigniter to do the views and user interface. I've been reading lots of posts on stackoverflow which recommended node.js or socket.io. Yet I've also run across APE(Ajax Push Engine). I don't really know much about either and was wondering which to use.
I read up on node.js and saw lots of good things about it, but the major thing about it that worries me is that it's relatively new and doesn't have lots of real world websites testing/using it.
On the other hand, APE does. And it looks similar to node.js. But like I said, I don't know enough about either to know which one to choose.
Which one is better at creating a chat app?
Thanks!
I played a little bit with node.js, tried out socket.io - but in the end did a big project with APE.
I think, as always, there is the question of what you want to achieve. Only comparing the server parts: With node.js you get a machine that won't do anything on it's own, you need to write it yourself (or use libraries) With APE, the handling of channels and connections is already built in (compiled C). Still you need to build parts of your own logic on top with JS - or use the examples.
On the client side, socket.io provides a client framework with three commands - and APE has it's APE_JSF that handles the connections (which brings more functionality than socket.io regarding channels)
Personally, I prefer APE, even though there is a lack of documentation for beginners. However, keep in mind that APE won't deliver files/images, it's not a full Web-Server but optimized for real time push where it can handle ~10K concurrent users
Like you, I'm not familiar with APE, however socket.io on node.js comes with a chat app as it's main example app.
True, there aren't a lot of sites using Node.js right now. Socket.io, however, is probably considered Node's 'Killer App', and thus has relatively a lot of talk/work done with it.
I'm presuming APE has stable APIs, though, which socket.io might not necessarily have - The 0.7 version was a pretty broad, API-changing update, for example. This might happen less often with the publication of the socket.io spec.

Resources