Aljaxus

"we've got a full video on cable management that you can check out here" *nothing apprears*

I have no clue about what your project looks like, how it works, not how it will be used. But if there's one advice that I can give you it's that you should really, really move away from application hosting on Windows as soon as possible. Sure, xampp or (wampp) are very easy to setup - but running things on Apache is not the best way of doing things by far (a very simple attack is slow loris and there's quite a few more...). Welp, I "tossed" my two cents, have a good one

Firefox, love every part of it.

// I came here to try and help a bit, but damn this thread confused me so much I can't even describe it. Amazing.

Well... I dunno if it's available for Windows, but I would recommend KdeConnect. It's amazing - speaking from experience, currently using it - on Linux though, so I can't say how it is on Windows :thonk:

There are written standards for all these protocols (IMAP, SMTP, POP, ...) It's internet traffic - you have protocols like http(s) for webpages/webapps (gmal.com / outlook.com) and then you have SMTP - which is for example most likely used by this very forum software to send you emails when needed - and FTP and many, many other well-known protocols. These are just the standardized ways that are used by different services to communicate with each other. Like the example given above (the linustecttips.com forum), when the forum software "decides" that it's time to send you an email it most likely doesn't sent it by itself. It constructs the email content (and other stuff like who to send it to etc...) and then it just passes that information to the email server (something like gmail and outlook - not the webpages, but the services that are used for actual email processing. you as a user don't really interact with these) which then sends the notification email to Google's (or Microsoft's) email servers which then process the email, verify that the sender it "leggit" (to determine if it's spam or phishing, etc..) and if everything checks out it stores it and send you a "HEY! you have a new email" to your phone. It's a bit more complicated than that, but I hope you get the point

This would be an interesting project :thonk:

Hey @QChoumont Alrighty so you're basically developing a simple chat webapp with an android client - but the client doesn't really play any significant role in this play. It's just a "side character". I'll try to write a short tutorial on how I would personally approach this task. I'll try to explain most of the things that I think you would not know about - if there is anything that you'll still find too complicated ping me, or even better send me an email (google my nickhandle and you'll find it) because I really, really rarely come here. The whole thing Imagine this; you have three services1; the database2, a reverse proxy3 and the API4. (edit 1) These small numbers after these terms are references to the thingy at the very bottom of the post. Read that shit database Let's start with the most obvious stuff - the database - you'll use it to store data. You need to make sure that your API can connect to it. I don't know what you're planning to use (or what you have to use) and it really doesn't matter. The only thing that you need to make sure is that if possible, only the API service can access it. Do not expose it to the internet, do not expose it to LAN, it should be only accessible to the API service. And of course there are exceptions - when you have clusters, distributed systems, your services running "in the cloud" (eg. Kubernetes or similar solutions) but we're not here for that. reverse proxy If I were you - and I suppose you're just starting out - I would google for "how to setup a reverse proxy for web server" and I would most likely find a blog post or some answer on stackexchange talking about Apache (or httpd) and I'd use that. Don't. Just use NGINX. It's better, it's faster, it's easier to configure especially when you get used to it and the configuration uses an actually readable format (.conf) unlike Apache... Now all you have to do it tell your reverse proxy to serve static files by default and when the request is made to the /api endpoint, you simple proxy it to your API service. You can proxy requests to UNIX socket files or to a TCP/IP socket. TL;DR and a simple version of that thing above is as follows: When you have a server5 it has to "listen" to a socket, so clients can actually talk to it and request stuff. When a service is bound (when it "listens") to IP sockets - also known as "ports" - it's reachable over the network. When it's bound to a UNIX socket it communicates with its clients over a file on your filesystem (it's more complicated than that, but for you at the moment... ...well that's what it looks like. It's a file, when on linux you usually find them in /var/run/SERVICE/SERVICE.sock or /var/run/SERVICE.sock where "SERVICE" is replaced with the service's name ) Your reverse proxy should bind to IP socket (port) 80/tcp (aka "port 80") which is the default port for HTTP traffic. In case you'll want to setup HTTPS too, you'll have to tell it to bind to port 443/tcp too. And you'll need to setup certificates for your domain. But this is beyond the scope of this "project". the API This is your - if I remember correctly - java-based server. Since we're running the reverse proxy on the same system as the API, you should really just bind this server to a UNIX socket. If you want you can bind it to a IP socket too, but it's useless, because all your clients should access it through the proxy anyway. The API is the part of the backend which will **actually** process the requests. When a client posts a new message it will send you a request which will be telling you what the content it, who the client is and in what channel they are posting. now all you have to do is verify that the client is actually logged in (if you'll have authentication), parse the content to make sure you don't have an XSS attack in the content itself (or any other "malicious stuff") - you can do that simply by only allowing ASCII characters, it will make your chat app restrictive as hell, but at least it'll be "safer" and easy enough to implement - then you save the record and notify all clients about the new message. About notifying clients ... this might be a bit more complicated - so you should really just stick to "pooling" instead of "web sockets". Google for more info, but TL;DR is - with websockets you keep the client<>server connection alive so not only the client can "start the convo" with the server, but also the server can just tell the client "hey, take this new data and process it". In comparison to this, "pooling" is the method of having the client ask the server "is there anything new" every {{ insert your short interval here | one second? }}. Instead of having an open connection between the server and the client where the client can reach out to the server and the server can reach out to the client too, you just have the client spamming the server every second for new events. Websocket are the more "elegant" (and better) approach, but pooling is much easier to setup. If I were you I would go with pooling in this case. It's a simple app that should never to go production, it'll be served over plain HTTP, so everyone on the network can see what you're seeing... Don't bother. static files Well these are the "website" files that your reverse proxy will serve to the browsers when they visit your website. They don't have the chat client, the UI, like the android app will have, so you need to serve the UI to them. They will, just like the android clients, communicate with the API, but they first need the logic that allows them to even know how to communicate and this is what these files are here to do. All you need is a simple html file with basic structure, a css file for styling and a JS file for some basic logic. You probably know this already for some time now, so Imma stop here - - - - 1) Service - I am referring to an application / program which does not have an UI and is run on a server (non-client machine). An example would be a webserver, database, cron etc. It does not have to be a server that serves data. It's just a piece of software that runs on your machine in the background doing stuff that it's made to do. 2) database - a database server5. Presumably mariadb, postgresql, mongodb, firebase, firebird, sqlite etc. 3) reverse proxy - usually an HTTP server5 which is used to proxy traffic to services that are not to be access directly. Eg. use NGINX to proxy all requests that are posted to /api/v1 to the old API service, proxy all /api/v2 requests to the new API service and for all other requests serve static files from /var/com.myapp/static folder. 4) API - application programming interface. This is basically the "brain" of your application. Your clients should NEVER communicate directly with the database, and this is what makes sure that they don't. 5) Server - it's a service that serves stuff. Be it to clients (users), eg. a web server serving web content to your browser, or to other services, like a database that serves data to your API4. I'm sure I have not explained some stuff that is obvious to me, but isn't to you. As said above - email me (well you can probs also just tag me and I should get the mail notification... I dunno, try it I guess, we'll see if I'll reply in less than an hour ) Also, if you need a server to test stuff - feel free to ask - we'll hop in DMs and I can give you a VM for free. Can't give you a public ip, because I don't have any left, but you will still be able to access the server directly via a VPN :thonk:

I am no "professional" by any means - I am not even fully employed - so take this with a grain of salt... And keep in mind - everything is just my opinion I will not tell anyone what to do, because I don't have enough experience in working field at all. All I can tell you is the following; I am just 18 years old, though with decent experience in full-stack development, and I am "partly" employed in a semi-large company as a programmer - I can't be full-time because I'm still a student (and laws here, etc..). I develop internal applications with "progressive" technologies such as NodeJS for backend, VueJS, Webpack, Service workers for frontend, etc... The company is selling machines for casinos, machines themself (hardware) and software. Their software is written in C, C++ and maybe they'll switch to Java if they'll start a rework at some point. C++ and Java are quite popular in the fields of gaming industry (gaming as "casino gaming"). There are also loads of applications for internal company organisation which are all written in Java and C++ If you're looking to get in some more "current-gen" work you should look into mostly web-related technologies. Get familiar with Javascript, NodeJS to be more specific, and at least ES6 if possible with latest standards. If you will follow the NodeJS path, you should also look into GraphQL - a very good standard for HTTP API development. Look at it like an improved version of RESTful API standards (you should also learn at least the basics of RESTful APIs). Don't forget about MongoDB - it's a bit weird if you're already familiar with MySql, but if you're starting a new project and you can pick between those two, I'd go with Mongo. It needs a bit more setup, but it gives you much more freedom and flexibility. Speaking of Docker - learn it. It's very easy, it will help you A LOT. Especially when you're working on some backend stuff. In most cases servers run on linux-based environments. Docker helps you run your backend app in linux environment, while you're using Windows - without any virtualization. It's great - lean it. Long story short... In my opinion you can't go straight to some language / technology and be like "I will learn this because this is what it is used at the moment" because at the time you'll get good enough, it might not be an industry standard any more. Well this probably doesn't hold true for C++ or Java, but it might for some other technologies. If you have enough time - find some interesting, yet easy, project and try to complete it in a few different technologies. You should learn how to use Docker in any case. This post might be a bit messy, if anyone thinks I should correct something or needs some explanation, please `@` me.

Linux time.