uws-react-native 0.0.3 → 0.0.4

package/README.md

@@ -61,21 +61,15 @@ uws-react-native is still in heavy development and research. All the uWebSockets
 
 There are development and research things that you can read for your informations, especially if you are already familiar with uWebSockets. The most things are because of the React Native's architecture differentiation compared to the casual uWebSockets server program.
 
-### Performance & Stability
-
-This library is indeed focusing on performance, but we will focus more of it later until we reach the stability of uws-react-native due to [threading](#threading) issue. It does not mean uws-react-native will performs badly in terms of speed, but it is not stable enough in under a stress situation because we run uWebSockets only in one thread.
-
-I have tested a stress test in an Android device. A lot of incoming request roughly 100 requests per second in roughly 5 seconds for files uploading (multipart/form-data) may crash the app. We do not have the proper benchmark yet, but it is as we expected from one thread only. I am keeping my eyes on this issue to keep improving the performance.
-
 ### Threading
 
 We are embracing the main chaos of supporting uWebSockets in React Native architecture, which is to prevent UI/Main thread from blocking.
 
-Intentionally, we make the uWebSockets runs in another thread, therefore we have to make sure the communication safety between uWebSockets runner thread to the JS thread and vice versa. In theory, we can make uWebSockets runs in the main thread, but the app will be unusable, and then force closing the app is the only way to stop the server.
+Intentionally, we make the uWebSockets will runs in another thread, therefore we have to make sure the communication safety between uWebSockets runner thread to the JS thread and vice versa. In theory, we can make uWebSockets runs in the main thread, but the app will be unusable, and then force closing the app is the only way to stop the server.
 
 Yet, we only use one dedicated thread per uWebSockets run. I am in my own research to improve this by maximizing it to the hardware concurrency limit, but also to be careful about JavaScript runtime, because we have no control of it.
 
-We have another issue because of the uWebSockets runs in another thread. From the JSI C++ side, we have to assume any JS function as a callback especially the route method handler is asynchronous. We cannot make a sync call to the JS function from an arbitrary thread to the JS thread, and it makes JS call to the uWebSockets runner is also late.
+We have another issue because of the uWebSockets runs in another thread. From the JSI C++ side, we have to assume any JavaScript functions as a callback especially the route method handler are asynchronous. We cannot make a sync call to the JavaScript function from an arbitrary thread to the JavaScript thread, and due to the asynchronous call, it makes the JavaScript call to the uWebSockets instances is late.
 
 There some topics you may to read regarding this threading research
 

package/cpp/UwsReactNativeModule.cpp

@@ -68,12 +68,16 @@ facebook::jsi::Object UwsReactNativeModule::getParts(facebook::jsi::Runtime &rt,
   /// See /uws-react-native/package/src/modules/getParts.ts
 
   if(!body.isArrayBuffer(rt)) {
-    /// undefined
-    return facebook::jsi::Object(rt);
+    throw facebook::jsi::JSError(rt, "First argument of `getParts` has to be an ArrayBuffer");
   }
 
   auto arrayBuffer = body.getArrayBuffer(rt);
 
+  if(arrayBuffer.size(rt) == 0) {
+    // undefined
+    return facebook::jsi::Object(rt);
+  }
+
   auto mp = uWS::MultipartParser(contentType.utf8(rt));
   if(mp.isValid()) {
     mp.setBody(std::string_view(reinterpret_cast<char *>(arrayBuffer.data(rt)),

package/cpp/app/HttpRequestObject.h

@@ -1,24 +1,18 @@
 #pragma once
 
-#include <ReactCommon/CallInvoker.h>
-#include <algorithm>
-#include <cmath>
 #include <jsi/jsi.h>
+#include <memory>
 #include "RecognizedString.h"
 #include "uWebSockets/HttpContextData.h"
 
 namespace uws_react_native {
 
+/// Only use this in JavaScript thread
 class HttpRequestObject : public facebook::jsi::Object {
 
 public:
   HttpRequestObject(facebook::jsi::Runtime &rt,
-                    uWS::HttpRequest *pReq) : facebook::jsi::Object(rt) {
-
-    /// Without shared pointer
-    /// uWS::HttpRequest returns weird behaviour for some methods like
-    /// getHeader, getUrl, and getParameter
-    auto req = std::make_shared<uWS::HttpRequest>(*pReq);
+                    const std::shared_ptr<uWS::HttpRequest> &req) : facebook::jsi::Object(rt) {
 
     this->setProperty(rt,
                       "forEach",
@@ -135,7 +129,7 @@ public:
       }
 
       return facebook::jsi::String::createFromAscii(rt_1,
-                                                   std::string(query));
+                                                    std::string(query));
     }));
 
     this->setProperty(rt,
@@ -164,10 +158,8 @@ public:
       return {rt_1, thisValue};
     }));
 
-    req.reset();
-
-  } // HttpRequestObject
+  } // HttpResponseObject
 
-};
+}; // HttpRequestObject
 
-}
+} // namespace uws_react_native