I was searching the internet for hours on end hoping to find any kind of built-in functionality to support byte-range requests (https://www.keycdn.com/support/byte-range-requests) within nestjs. I am coming from the .NET world where we have got something like this:
[Route("/streams/{id}")]
public IActionResult Clip(string Id) {
... more code ...
return File(myDataStream, "video/mp4", enableRangeProcessing: true);
}
Is there any analogous, similiar or comparable functionality within nestjs which I had then simply overlooked or do I really have to develop this rather cumbersome yet pretty common use-case on my own?
Kind regards
Samuel
Related
While trying to organize the code of my first NodeJS-express project, I ran into some doubts about the use of namespaces, modules and classes. When to choose one? When another?
For example, my project is structured (simplifying) in.
routers -> controllers -> services -> repositories.
The possibilities I thought of to manage these "entities" are the following:
Classes
Classes with static methods
Singletons
Simple module export
Namespaces
Classes
I thought of avoiding them right away, since the above-mentioned entities do not need to memorize any state. Furthermore, they would complicate the code due to the need to be instantiated.
Classes with static methods
They are correct? Or rather a simple namespace or simple export of the modules?
Class + Singletons
A way of organizing the code in a "nicer" way than the simple class, but which does not convince me, since reading on the net that the singleton in TypeScript is replaceable with the namespace.
Simple module export
The way I thought to implement immediately, for example in this way (file user.repository.ts):
const add = async (user: User): Promise<void> => {
if(await canBeAdded(user)) {
//save user;
} else {
// throw error
}
}
export const UserRepository = {
add
}
It's corrects? Or am I not properly using what TypeScript offers? Being the first time I use this language, I would like to be sure I chose the right path.
Namespaces
Are they a better choice to develop the code published above? Are you advised against?
Thank you in advance for the answers! Any advice is welcome!
P.S. I know that, once the TypeScript is compiled, in Javascript the classes are practically syntactic sugar. What I'm interested in knowing are the best practices for writing good code in TypeScript.
I like the jhipster entity generator.
I often get to change my model and regen all entities.
I wish to keep the generated stuff and override for my needs.
On angular side, it is quite easy to create a new service extending the default entity service to do my stuff.
On java side, it is more complicated.
For example, I override src/main/java/xxx/web/rest/xxxResource.java with src/main/java/xxx/web/rest/xxxOverrideResource.java
I have to comment #RestController in xxxResource.java. I tried to give it a different bundle name from the overrided class but it is not sufficient : #RestController("xxxResource")
In xxxOverrideResource.java, I have to change all #xxxMapping() to different paths
In xxxOverrideResource.java, I have to change all method names
This allow me to keep the CRUD UI and API, and overload it using another MappingPath.
Some code to make it more visual. Here is the generated xxxResource.java
/**
* REST controller for managing WorldCommand.
*/
// Commented to prevent bean dupplicated error.
// #RestController
#RequestMapping("/api")
public class WorldCommandResource {
private final WorldCommandService worldCommandService;
public WorldCommandResource(WorldCommandService worldCommandService) {
this.worldCommandService = worldCommandService;
}
#PutMapping("/world-commands")
#Timed
public ResponseEntity<WorldCommand> updateWorldCommand(#Valid #RequestBody WorldCommand worldCommand)
throws URISyntaxException {
log.debug("REST request to update WorldCommand : {}", worldCommand);
...
}
Here is my overloaded version : xxxOverrideResource.java
/**
* REST controller for managing WorldCommand.
*/
#RestController("WorldCommandOverrideResource")
#RequestMapping("/api")
public class WorldCommandOverrideResource extends WorldCommandResource {
private final WorldCommandOverrideService worldCommandService;
public WorldCommandOverrideResource(WorldCommandOverrideService worldCommandService) {
super(worldCommandService);
log.warn("USING WorldCommandOResource");
this.worldCommandService = worldCommandService;
}
#PutMapping("/world-commands-override")
#Timed
public ResponseEntity<WorldCommand> updateWorldCommandOverride(#Valid #RequestBody WorldCommand worldCommand)
throws URISyntaxException {
throw new RuntimeException("WorldCommand updating not allowed");
}
With the xxxResource overrided, it is easy to override the xxxService and xxxRepository by constructor injection.
I feel like I am over thinking it. As it is not an external component but code from a generator, maybe the aim is to use the tool to write less code and then do the changes you need.
Also, I fear this overriding architecture will prevent me from creating abstract controller if needed.
Do you think keeping the original generated code is a good pratice or I should just make my changes in the generated class and be carefull when regenerating an entity ?
Do you know a better way to override a Spring controller ?
Your approach looks like the side-by-side approach described here: https://www.youtube.com/watch?v=9WVpwIUEty0
I often found that the generated REST API is only useful for managing data in a backoffice and I usually write a complete separate API with different endpoints, authorizations and DTOs that is consumed by mobile or end-users. So I don't see much value in overriding REST controllers, after all they are supposed to be quite thin with as little business logic as possible.
You must also consider how long you want to keep this compatibility with generated code. As your app grows in complexity you might want to refactor your code and organize it around feature packages rather than by technical packages (repository, rest controllers, services, ...). For many reasons, sooner or later the way the generated code is setup will get in your way, so I would not put too much effort into this compatibility goal that has no real business value especially when you know that the yearly released major version may break it because of changes in the generator itself or more likely because of changes in underlying frameworks.
I have code using AutoMapper 3.2.1.0 that uses the method ToNullSafeString().
I upgraded the NUGet package to 4.1.1.0, and I can no longer find the method in their package.Does anyone know the recommended approach to replacing the function? Is there a new construct that is functionally equivalent? If so, I cannot figure what it is. Nor can I find any mention of why it was removed.
This question has actually been answered pretty well in a couple of comments below it. For completeness, here are a couple of actual implementations of solutions.
Short answer
Probably both the simplest and the best solution: Replace all instances of .ToNullSafeString() with ?.ToString(). This does the same, but uses functionality built into newer versions of .Net instead of relying on an external extension method.
Alternative answer
If you've got a bunch of calls to the ToNullSafeString() method from the earlier version Automapper, and for some reason or other you can't or don't want to go through all your code and edit it away right now, you can use this instead.
Add the following class to your project, and make sure it can be reached from any classes that previously called the Automapper-method. Those calls will then automatically point to this instead.
public static class NullSafeStringHelper
{
public static string ToNullSafeString(this object value)
{
return value?.ToString();
}
}
a few days ago i posted a question about Serializing the ResponseStatus property with BinaryFormatter. Mythz pointed out it wasnt the fastest way to go, so i decided to switch to another formatter. Tried ProtoBuff and MsgPack, and am on ProtoBuf now.
My real question is: im trying to grasp how Protobuf knows how ServiceStack Dto's should be serialized. I tried adding all the possible attributes to my existing dto, ProtoContract and ProtoMember(0,1,2,3,etc), but also DataContract and DataMember.
On top of that i dont use ServiceStack's own client, but try to serialize the request to an existing stream.
If i dont do this:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Add (typeof(NameSpacePlaceholder.Service.Dto.GetNodes), false);
i get an error about Types and Contracts that cannot be infered,
If i do add that piece of code, all continues great, but the deserialized object is empty.
Im using this to Serialize:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Serialize (ms, myObject);
and to Deserialize:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Deserialize (ms, null, deserializationType);
I think im missing something here. Could it have something to do with namespaces? I looked into some code from ServiceStack.ProtoBuff, it isnt so hard to understand, but i cannot get it going.
Things that are unclear to me now:
Is there a need to add Attributes to the existing DTO's ? (in ProtoBuf V2 i can also do it in code, i read, but for now i can also alter the existing DTO's)
Do i need to initialize the Request(and response) DTO's, in my Client(Serialize) as wel in my Server(Deserialize)
Is there some reason why i should not be serializing to my own Stream ?
Many thanks,
I hate it to post an answer myself, it means i havent searched enough in the first place
I learned the following attributes are very important:
[ProtoContract]
[ProtoMember(X)]
[ProtoInclude(X,typeof(DerivingClass))]
For now i learned something new: why class inheritance in DTO's is not advisable.
I've got it going now, and will try to make it real-life friendly..
I fell in love with Groovy and try to use it more and more. Now I have to work with Oracle Forms Jdapi library. When working with this library, you write a lot of code like this:
JdapiIterator progIterator = getWorkForm().getProgramUnits();
while(progIterator.hasNext()) {
ProgramUnit currProgUnit = (ProgramUnit) progIterator.next();
...
}
and of cource I would like to write
getWorkForm().programUnits.each {
...
}
However, I never wrote a Groovy interface to an existing Java library and need some assistance. I know about Groovy 2.0's extension methods, but in that case I am thinking about a class with the same name in a different namespace which delegates only to the functions I would like to keep.
What is the best approach for providing the each functionality, but also all other closures applicable for collections? I would appreciate if you point me in the right direction!
The only method you need to provide is the iterator() method. You then get all of the Groovy Object iteration methods (each(), find(), any(), every(), collect(), ...) for free!