Anyone done much with NodeJS and open APIs (github, google docs, etc)?

[darrylmg]

As ever, Google is your friend.

I get your point, but I don't agree with it.
I think asking questions on here enlightens more than just the OP, can open the space to ideas, allows us to connect with each other and draws traffic (and maybe new members).
As an example, I now know that yourself and nickfitz know about Python. In return you know that I mess about with Red Hat and CentOS. Someone might find this thread (ironically via a Google search - I know) and decide to join and contribute.

For anyone interested, my only bit of Python that I have written is actually executed via stdin, inline inside a HERE document in a Korn shell script. You don't get any bytecode output, I looked. Checked with strace after nickfitz confirmed.
Would I get a performance benefit from moving it out to a separate python script? Maybe. I might give it a go.
I also got the whole Python 3 stuff ported across from CentsOS 6.7 to RHEL 6.7 using the SCL to get it downloaded on CentOS, then just copy across to RHEL and adjust the shebangs for the new target location path. Works a treat and completely RPM-less.

I also saw a nice demo last week, using CDS to very quickly create a model and deploy to sqllite before running it on node.js for the generated oData service. Unbelievably slick! Might give node.js a try out on Azure.
If you're looking at node.js, I highly recommend looking at CDS for node.


Sent from my SM-T280 using Contractor UK Forum mobile app

[Cirrus]

Are you certain Python gets compiled?

As ever, Google is your friend.

[darrylmg]

If you look in a directory containing Python code that's been run, you'll see that each .py file has a corresponding .pyc file, which is the compiled bytecode - for Python 3, they'll be in a __pychache__ subdirectory, but Python 2 had them alongside each other. The compilation step happens when a file is first loaded by the Python interpreter, is very fast, and is only done again if the source file has changed, so there's no real performance advantage to distributing the bytecode. In fact, I see that some examples on my own machine that have been run under Python 3.6 have a -36 suffix before the .pyc extension, so presumably they are tied to that version, which would prevent me upgrading to 3.7 if they were all I had.

More on Python bytecode: An introduction to Python bytecode | Opensource.com, Understanding Python bytecode | Synopsys

Thanks.
It's freaky how things work out sometimes.
Literally the day after thegreenbastard confirmed about the bytecode thing, I was requested to see if I could find a way of getting some Python 2.7 code running on a RHEL 6.7 server (2.6 only, unless you install some community repo stuff) without involving the Linux admin team (uh oh).
So away I went to read all about bytecode to see if I could somehow shortcut some issues I was seeing in my quest to not involve the admin team (they really are miserable and I work in a heavily politicised environment).
Now if we could just discuss next week's lottery result...

Sent from my SM-T280 using Contractor UK Forum mobile app

[NickFitz]

Are you certain Python gets compiled?
I know you can make a Python script portable by wrapping it with the interpreter, but I honestly didn't imagine any bytecode was ever produced. If it was possible to produce bytecode then wouldn't people distribute some of their stuff as bytecode for performance reasons? I've not noticed any (could be me not being very observant though).

Sent from my SM-T280 using Contractor UK Forum mobile app

If you look in a directory containing Python code that's been run, you'll see that each .py file has a corresponding .pyc file, which is the compiled bytecode - for Python 3, they'll be in a __pychache__ subdirectory, but Python 2 had them alongside each other. The compilation step happens when a file is first loaded by the Python interpreter, is very fast, and is only done again if the source file has changed, so there's no real performance advantage to distributing the bytecode. In fact, I see that some examples on my own machine that have been run under Python 3.6 have a -36 suffix before the .pyc extension, so presumably they are tied to that version, which would prevent me upgrading to 3.7 if they were all I had.

More on Python bytecode: An introduction to Python bytecode | Opensource.com, Understanding Python bytecode | Synopsys

[TheGreenBastard]

Are you certain Python gets compiled?
I know you can make a Python script portable by wrapping it with the interpreter, but I honestly didn't imagine any bytecode was ever produced. If it was possible to produce bytecode then wouldn't people distribute some of their stuff as bytecode for performance reasons? I've not noticed any (could be me not being very observant though).

Sent from my SM-T280 using Contractor UK Forum mobile app

You can output bytecode and distribute it, but there's no performance benefit outside of startup cost when compared to a Python source file, you just jump the bytecode compilation step.

[darrylmg]

I have a feeling Python typically compiles to bytecode. When you run a Python source program, it checks whether a matching bytecode image already exists. If there is one, it runs that rather than the source. Also I believe it will run the bytecode in the absence of a matching source file. This allows Python 'compiled' applications to be distributed.

Are you certain Python gets compiled?
I know you can make a Python script portable by wrapping it with the interpreter, but I honestly didn't imagine any bytecode was ever produced. If it was possible to produce bytecode then wouldn't people distribute some of their stuff as bytecode for performance reasons? I've not noticed any (could be me not being very observant though).

Sent from my SM-T280 using Contractor UK Forum mobile app

[Cirrus]

I guess this is similar for all interpreted, not compiled languages like Python

I have a feeling Python typically compiles to bytecode. When you run a Python source program, it checks whether a matching bytecode image already exists. If there is one, it runs that rather than the source. Also I believe it will run the bytecode in the absence of a matching source file. This allows Python 'compiled' applications to be distributed.

[jconway]

Thanks. Yes, all the server side stuff.
What you're saying is the only products you can safely write and sell are SaaS?

I mean, if you wanted to just charge a one-off fee and grant them unlimited usage of your server-side app, through a secure API, then you could do that. Your app code would remain server-side and controlled by you. You would simply guarantee that following the purchase they would have unlimited access to that version of the app running server-side. However I imagine most customers would prefer a SaaS business model, if they can't download and install the software on their local machines.

Because anything which would require deployment of the server side stuff on a client's infrastructure, would be easily stolen.

Correct. Whoever has access to the server-side hosting/infrastructure will have access to your code.

(Though I'm pretty sure there are ways of coding a back-end so that the source code can't readily be accessed even if the user does host the back-end themselves. Maybe certain configurations of .NET would allow you to distribute your code as a DLL that would run through IIS. But if we're talking NodeJS, it would definitely need the source code to operate, so you wouldn't be able to avoid your client having access.)

[darrylmg]

Assuming you're referring to the server-side code (the code which renders the web page) and not the client-side code (the HTML/CSS/Javascript that gets downloaded and executed in the user's web browser), then the end-user will not have access to it.

As long as you're hosting your server-side code in a safe place, e.g. a password-protected hosting account or cloud hosting service, then no one should be able to access your server-side code but you.

Thanks. Yes, all the server side stuff.
What you're saying is the only products you can safely write and sell are SaaS?

Because anything which would require deployment of the server side stuff on a client's infrastructure, would be easily stolen.

Sent from my SM-T280 using Contractor UK Forum mobile app

[jconway]

Something I've never understood about NodeJS is if you build something that is great and you want to sell as a product, how do you protect it from being blatantly copied?
I seem to remember I had the same thoughts about ASP many years ago.
Does this limit the usefulness or is there some sort of obfuscation that can be applied?

Assuming you're referring to the server-side code (the code which renders the web page) and not the client-side code (the HTML/CSS/Javascript that gets downloaded and executed in the user's web browser), then the end-user will not have access to it.

As long as you're hosting your server-side code in a safe place, e.g. a password-protected hosting account or cloud hosting service, then no one should be able to access your server-side code but you.

[hungrybear]

Something I've never understood about NodeJS is if you build something that is great and you want to sell as a product, how do you protect it from being blatantly copied?

I guess this is similar for all interpreted, not compiled languages like PHP, Python, JavaScript etc.
There are plenty of commercial applications and packages built with these.

You can use the obfuscation libraries for JavaScript, there are few.

[darrylmg]

Yes, NodeJS has gained quite a bit of server side development ground during last few years.
Its runtime engine v8 has reached quite good performance, and its improvements are supported / maintained by Google.

For me personally JavaScript as a language took a bit of time to adopt to, specially coming from OO app development world. But, with recent ES6 spec things are improving.

It was just not build with OO concepts like inheritance or polymorphism in mind. Like mentioned above, you can always use TypeScript with transpiler.

Another important bit is not to use NodeJS where it doesn't belong - computation heavy server side applications.

Something I've never understood about NodeJS is if you build something that is great and you want to sell as a product, how do you protect it from being blatantly copied?
I seem to remember I had the same thoughts about ASP many years ago.
Does this limit the usefulness or is there some sort of obfuscation that can be applied?

Sent from my SM-T280 using Tapatalk

[hungrybear]

I want to knock up some little tools and I found a service to host NodeJS scripts for me (datafire.io) which suits me better than setting up a server specially.
I've done some web-dev back in the day but hated it... however JS as a language was OK. I normally develop in C++, C#. Is there anything particularly complicated or to be scared about here or is it just a case of reading the API docs and maybe buying a book on NodeJS? It seems like a useful string to add to my bow as a predominantly server-based developer anyway so might be worth investing a bit of time?

Yes, NodeJS has gained quite a bit of server side development ground during last few years.
Its runtime engine v8 has reached quite good performance, and its improvements are supported / maintained by Google.

For me personally JavaScript as a language took a bit of time to adopt to, specially coming from OO app development world. But, with recent ES6 spec things are improving.

It was just not build with OO concepts like inheritance or polymorphism in mind. Like mentioned above, you can always use TypeScript with transpiler.

Another important bit is not to use NodeJS where it doesn't belong - computation heavy server side applications.

[Freewill]

I'm a massive fan of NodeJS because its very easy to get up and running with, and it has an incredibly rich open-source ecosystem compared to C# and C++ (which I also develop with). It is also doesn't care whether you are using Mac/Windows/Linux.

My advice would be to dive right in and start publishing your own little packages to npm. VSCode is the best editor to use as it has integration which provides intellisense for the built in Node APIs and other npm packages.

You have a choice of using plain JavaScript or TypeScript. TypeScript is awesome but you may find it easier to start with plain JavaScript and then move to TypeScript as your projects get bigger and you get more comfortable with the tools. JavaScript has probably improved a fair bit since you last used it, so maybe read up on some of the new features/syntax.

If you want to integrate with a range of APIs I have heard really good things about OneGraph https://www.onegraph.com/. Even if you don't use it, imitating the same approach of creating a GraphQL API which provides a single access point to different services should be an interesting project. I also expect there soon to be increased demand for server developers who have created GraphQL APIs.

HTH

[d000hg]

I want to knock up some little tools and I found a service to host NodeJS scripts for me (datafire.io) which suits me better than setting up a server specially.
I've done some web-dev back in the day but hated it... however JS as a language was OK. I normally develop in C++, C#. Is there anything particularly complicated or to be scared about here or is it just a case of reading the API docs and maybe buying a book on NodeJS? It seems like a useful string to add to my bow as a predominantly server-based developer anyway so might be worth investing a bit of time?