Based & Redpilled.

Parameters should be camelCase

public Myclass(int myVariable) {

MyVariable = myVariable;

}

Sith: git push --force

Jedi: git push ---force-with-lease

If you have request/response model then I would make contracts (model classes) shared between client and server. And provide class to client for calling server e.g. MyProtocolClient. This client would have methods for sending and receiving individual messages and wil ltake care of whole socket logic and serialization.

public CreateUserReponse CreateUser(UserModel);

Where UserModel is DTO which get serialized and and flushed to socket (server also knows UserModel), server responds, client deserializes and produces CreateUserResponse.

This way, programmer is completely abstracted from your protocol, does not have to deal with json/binary etc...

I would do this approach for request/response oriented protocol (RPC/REST). Ofc your use case might be different.

I relate to my entities like they relate to each other.

No

I want to be in control to what code my computer is executing. If I dont want my computer to download something, it sure as hell shouldn't.

The ads are way too pervasive, not to mention what they are executing is untrusted third party code a privacy disaster.

To google: I hope everyone promptly shits on your fast spyware and start using actual privacy respecting free (as in freedom) software, where corporate wont dictate you what can/cant't you do.

JS sort by default stringifies all the elements so its same as sorting ['6', '-2', '2', '-7'] hence resulting in lexical sort. To do numeric just do

arr.sort((a, b) => a - b)

@nothappy Not sure about minification, try doing production build. If they are not, eject and customize webpack config.

@Ghosty It's not heap buffer overflow. Its just OOM error.

CRA 2 has built in support for Sass. Install node-sass, and import .scss files directly.

If that's an option.

TCP -> RPC -> HTTP -> WCF -> REST -> RPC again

IMO GQL forgot many things REST improved.

Can't properly use DevTools, Cache proxies are useless, Backend has lower control over queries, Forces consumers to use GQL clients...

I think it will divide community between REST and GQL.

Simple stuff.

1. Request come to server

2. It's passed to router

3. It decides which controller and action will handle it

4. Framework binds the incoming data (Query, JSON, Form...) to the model

5. Action method runs and returns view/data

Some stuff is also executed before and after action method, like filters, middlewares... But this is the Flow...

Also good practice is to put app logic (data access/algo) in separate .dll and maintain Layered architecture. I usually go for 4-5 layers:

Data.dll <- Entities

Dal.dll <- Repositories

Core.dll <- Logic

MvcProject.dll <- Asp here

Also some Common.dll for shared stuff.

How about converting it to get only properties ? No calls and stringly typed props required. Object does not change its interface.

I like the concept of Frontend guy controlling data that's neat.

I hate that it uses only one endpoint, everything is POST, and result always 200 even on error, that sucks.

I am also getting the feeling it executes far more queries in DB than rest-like service where you control queries.

Overall I am still with REST.

It does make sense, in C. It has sme redundancy but its a valid code. Assignment is also an expression so the fllow is following.

1. Call try()

2. Assign its retudn val to var succeed

3. Expression of assignment is value assigned itself

4. negate the expr value

5. you know what while does, so...

Gurl, are you Electron app ? Cuz, all my memories are about you!

Sorry...

@tahnik I love new things, I just don't like reinvented wheels with historical mistakes just because big company is pushing it.

@nzeetee Of course, Blockchain Cloud Serverless AI. And the customers get wet =D

Yeah GraphQL... A horror story you can tell your kids and they start to piss themselves again.

Why to use (finally) industrial standard REST, when we can use RPC-like shit with one endpoint... Forget caching, tooling, methods, urls, even fucking json (for queries). Another shit which claims it's better that standardised, wildly accepted solution, while it locks you down to it like fucking crack. Every feature GQL has, can be with little effort, implemented by REST.

A: Why isn't your service using GraphQL ?

Me: Because we are not twats.

Resist the hipsterness, rise above, go REST.

Cap'n out.