Develop Reference

Nest.js Database Interoperability Questions

The question may seem voluminous - but in order to understand the essence in a different way, it seems extremely difficult to formulate it.
While reading the documentation and some other sources, I encountered a certain misunderstanding related to the variety of file types for interaction when working with the database:
.dao
.dto
.entity
.repo
Question:
How do these types of files differ conceptually in terms of functionality?
(If anyone has a detailed video or article on this topic, I will also be grateful for the link.)
There is also this microproject (working code) taken from the docks:
https://github.com/Mike-Kharkov/nest-perfect-goods/tree/master/src
What should the code for entering values into the database look like?
(what should be the name of this file, where should it be located from the point of view of the approach, and what specific code should be written there?)
For example, if I need to parse data (as I understand it from another service, it is correct to do this in this framework) and then put it in the database without a request via HTTP, then how to do it most correctly from the point of view of the approach?
P.S. I would be grateful for any constructive advice ..

.dao, .repo, and .entity are all pretty much the same thing. They're the ways that you define to talk with your database. There's a little give and take on the definition of the file, .entity is more of defining the table/entity in the database, but with something like TypeORM the entity becomes a method to talk to the database as well (either through the entity class or the Repository class).
DAO stands for Data Access Object, by the way, and you can read more about it and patterns around it on Wikipedia.
.dto is for Data Transfer Object which is usually the definition of how data is passed between services, or over the wire (incoming request, outgoing response, microservice body, etc). In NestJS we use DTO's for incoming request deserialization and validation, along with outgoing response serialization on occasion.

How To Encode HTTP parameters with Ruby and Javascript

I'm working on a Rails project with React for the frontend. I want to have some sort of encryption for parameters. For example:
def index
#foods = Food.page(secured_params(:page))
end
secured_params() method is defined in the main ApplicationController of the application.
I want this encryption to be very simple and computational effective. In simple words, it doesn't cause much overhead. With the same technique, the React based frontend should be able to encrypt the parameters' values before they get sent to the backend. On the backend, when it receives the parameters' values, it decrypts and checks if the values are valid. If not, the backend just stops without doing anything. I'm using this technique to avoid bots/crawlers on the Internet.

I found a similar thread on this: https://security.stackexchange.com/questions/17259/better-techniques-than-url-parameter-encryption
In short, people have different techniques. Some do and the other don't follow this approach. If you are on the same side and want to do this, here is one of the approaches: https://security.stackexchange.com/a/63371

Isn't it dangerous to have query information in javascript using breezejs?

Just starting to play with breeze.js because of the obvious gains in coding time, i.e. managing to access model data from the server direct within Javascript (I am a newbie here, so obviously bare with!).
In the past I have used the stock ajax calls to get/post data to the server, and I have used a few different client tools in the past to provide some help in querying local data, such as jLinq.
My question is this. Isn't it dangerous to have essentially full model query access in Javascript? I must be missing something because it looks like a really well thought through tool. In the past I have at least controlled what can be sent to the client via the backend query process, and again using something like jLinq etc I could filter the data etc. I can also understand the trade-off perhaps with gaining the direct query/none-duplicating local model problem, so just if anyone could provide some insight to this?
Thanks!
EDIT
Obviously I am not the only one, however I am guessing there is a reasonable response - maybe limiting the data being requested using DTO methods or something? The other question posted is here

It can be dangerous to expose the full business model. It can be dangerous to allow unrestrained querying of even that part of the model that you want to expose to the client. This is true whether you offer an easy-to-query API or one that is difficult to query.
That's why our teams are careful about how we construct our services.
You should only expose types that your client app needs. If you want to limit access to authorized instances of a type, you can write carefully prescribed non-queryable service methods. Breeze can call them just fine. You don't have to use the Breeze query facilities for every request. You'll still benefit from the caching, related-entity-navigation, change-tracking, validation, save-bundling, cache-querying, offline support.
Repeat: your service methods don't have to return IQueryable. Even when they do return IQueryable, you can easily write the service method to constrain the query results to just those entities the user is authorized to see.
Fortunately, you can blend the two approaches in the same service or in collaborating services.
Breeze gives you choices. It's up to you to exercise those choices wisely. Go out there and design your services to fit your requirements.

Breeze isn't meant to be your business logic in that sense. Keeping in mind the rule of thumb that if you do something in Javascript, anyone can do it, you ought to be restricting the visibility of your own service data as needed.
In other words, it's useful for you if you meant to make the data publicly visible anyway. But only expose the entities that you're happy exposing and allowing anyone to query; another way to look at it is that your API becomes a public API for your website (but not one you advertise and tell everyone to use).
I am personally not a fan of doing things this way as there is a dependency created on the schema of the backend implementation. If I want to make changes to my database tables, I now have to take my Javascript into consideration. I also lack in terms of integration and unit testing.
However, it can have its uses if you want to quickly build a website feature on non-sensitive data without having to build the service methods and various layers of implementation of it.

What about when you expose the Metadata? Isn't that considered dangerous. IMHO is not safe to expose metadata from the DbContext. I know you can construct metadata on the client, but the point is to do things as quickly as possible(if safe).

Are there any techniques to separate HTML structure from the underlying data?

Database access is often the slowest part of an application, so to accommodate that are there any techniques to respond to a request by:
sending a static HTML structure
running a query on the data store
once the data returns from the query, then push the data to the client (perhaps in JSON)
use JavaScript to update the HTML by adding text or changing value attributes
First, is this a bad idea? Having not found anything resembling this in my research over the last couple days I assume it is a bad one. However, if it is not, is it possible? And are there established techniques for doing this?

As has already been said, this is basically what an "ajax application" is. They are very easy to write nowadays, mostly because of the number of frameworks out there.
Check out http://sproutcore.com, http://javascriptmvc.com/ and http://cappuccino.org/ Those are "heavyweight" solutions, but depending on what you are building, that may suit your needs perfectly.
If those don't look like the sort of thing you want, I would take a look at http://dojotoolkit.org It is a javascript framework that pretty much handles everything you could imagine wanting to do in an integrated sort of way.
If you are already using jquery, the best bet may be something like http://documentcloud.github.com/backbone/, or http://knockoutjs.com/, or http://sammyjs.org/.

http://api.jquery.com/category/plugins/templates/
http://stanlemon.net/projects/jquery-templates.html

Generate JavaScript objects out of Django Models

I am performing a lot of JavaScript work in the browser and would like to have some of that backend functionality in the front-end. Specifically, it would be nice to have the functions get(), save(), all() and count() available to the client. Additionally, it would be great to have the field list of the model already available in the generated JavaScript object.
Whether the current user can read or write the records is a separate issue I will deal with using Django's authentication. For the time being, retrieval would be a start.
In short, is there code that would generate a JavaScript model from a Django model?
Thanks.

It sounds like you're looking for a complete JavaScript interface to the model and queryset APIs. I can't imagine that this would have ever been done or even be a simple task. Not only would you need to somehow generate JavaScript instances of models (much more than JSON serialisation provides, since you also want the methods) but you'd need to expose a web service that can handle every kind of DB-API call. I can't even begin to imagine where to start and the security issues may be too numerous to easily overcome.
The alternative (and much simpler) approach would be to use one of the various Django REST modules and JSON serialization. You could perform an AJAX GET request on a resource, which can be identified by a series of query parameters that would be equivalent to chained queryset filters. This would return the JSON representation of the model's values. You can then modify the JavaScript object and use an overloaded AJAX POST request to persist the changes back to the server. You wouldn't have access to the model's methods, so that functionality would have to be reimplemented but making any changes to a model should be straightforward enough - This is basically the JavaScript equivalent of using an HTML form to modify data.

You need a data serializer. You can do it with django built in serializers. It is documented on official django site. djangoproject_topics-serialization

I've started a project that I think does exactly what you're looking for. You can find it at
github_bumby_jslib. It currently only supports get(), but I'm hoping to extend this soon. Feel free to contribute patches :)
jslib is a Django application aiming to simplify AJAX integration with your Django projects.

It sounds like you want to JSON encode your object data. See JSON.org for more on the data format.

So it's been a while since I posted the original question and since then there has been a number of developments in Djangoland. Not least of which is a great little library called Django REST Framework. I will be using it on a new project and it's looking pretty kewl.
http://www.django-rest-framework.org