[sword-devel] Prototyping node-sword-interface web service

Tobias Klein contact at tklein.info
Sat Aug 17 14:29:42 EDT 2024


I did some benchmarks for the client/server based sword data transfer.

This is how long my function for requesting the chapter text takes in 
different scenarios.

The node-sword-web-api based server runs on an AWS VM. The client (Ezra 
Bible App) on my Linux laptop.

The scenarios have been simulated using the throttle tool (see 
https://github.com/sitespeedio/throttle).

*Scenario*
	*Performance for loading John 3 (NASB)*
2g: up:256 down:280 rtt:400
	4901ms
2g: up:256 down:280 rtt:400
(http compression enabled on server side)
	3677ms
3g: up:768 down:1600 rtt:150 	1820ms
3g: up:768 down:1600 rtt:150
(http compression enabled on server side)
	1501ms
Home DSL connection without throttling
	320ms
Home DSL connection without throttling
(http compression enabled on server side)
	302ms

Best regards,
Tobias


On 8/11/24 10:34 PM, Tobias Klein wrote:
> Hi Fred!
>
> I suppose the redundancy is a general issue of json or xml when having 
> long lists of elements.
>
> Http servers and clients support gzip compression (and other more 
> modern algorithms). That's something I could check to optimize the 
> data amounts that are sent when making requests on this web-based API.
>
> Best regards,
> Tobias
>
> Am 11. August 2024 21:03:26 schrieb Fred <fred.fredex at gmail.com>:
>
>> I'm just a lurker here, but... even though I've dabbled in json, I 
>> gotta say that is  horribly verbose! I'd be willing to bet oh, say, 
>> fifty cents that a slow link would perform poorly. since (as I 
>> understand it) it is the remote server sending all that, that there'd 
>> be no way to filter out all the redundant json on each verse, which 
>> I'd expect to make it much more slow-link-friendly.
>>
>> Fred
>>
>> On Sun, Aug 11, 2024 at 1:56 AM Aaron Rainbolt <arraybolt3 at gmail.com 
>> <mailto:arraybolt3 at gmail.com>> wrote:
>>
>>     Haven't been replying since I'm busy, but this is awesome. Thank you
>>     for actually giving my idea a shot! I'll have to experiment with
>>     it :)
>>
>>     On Sun, 4 Aug 2024 21:00:24 +0200
>>     Tobias Klein <contact at tklein.info <mailto:contact at tklein.info>>
>>     wrote:
>>
>>     > Hi Aaron & all,
>>     >
>>     > so, this whole thread about SWORD over network inspired me to play
>>     > with existing technology a bit.
>>     > The goal: Run Ezra Bible App accessing the SWORD modules via a
>>     remote
>>     > server instead of locally.
>>     >
>>     > I implemented a small web service API based on node-sword-interface
>>     > and expressjs.
>>     > See https://github.com/ezra-bible-app/ezra-bible-app-server
>>     <https://github.com/ezra-bible-app/ezra-bible-app-server>
>>     >
>>     > Example -
>>     >
>>     https://github.com/ezra-bible-app/ezra-bible-app-server/blob/main/routes/module.js
>>     <https://github.com/ezra-bible-app/ezra-bible-app-server/blob/main/routes/module.js>
>>     >
>>     > // Delivers the text of a chapter via the url
>>     > /module/<moduleCode>/chaptertext/<bookCode>/<chapterNumber>
>>     >
>>     > router.get('/:moduleCode/chaptertext/:bookCode/:chapter', (req,
>>     res)
>>     > => { const moduleCode = req.params.moduleCode;
>>     >    const bookCode = req.params.bookCode;
>>     >    const chapter = parseInt(req.params.chapter);
>>     >
>>     >    const chapterText = nsi.getChapterText(moduleCode, bookCode,
>>     > chapter); res.json(chapterText);
>>     > });
>>     >
>>     > See here for example server deployed on some AWS machine I quickly
>>     > set up. The following URL delivers the KJV text of John 5 as JSON.
>>     >
>>     http://ec2-13-48-148-192.eu-north-1.compute.amazonaws.com/module/KJV/chaptertext/John/5
>>     <http://ec2-13-48-148-192.eu-north-1.compute.amazonaws.com/module/KJV/chaptertext/John/5>
>>     >
>>     > Then I made some adjustments in the backend of Ezra Bible App,
>>     > implementing a "switch" in a few methods that normally access a
>>     local
>>     > node-sword-interface / SWORD installation.
>>     >
>>     > The respective example section in the Ezra Bible App backend looks
>>     > like this:
>>     >
>>     https://github.com/ezra-bible-app/ezra-bible-app/blob/web-api/app/backend/ipc/ipc_nsi_handler.js#L243
>>     <https://github.com/ezra-bible-app/ezra-bible-app/blob/web-api/app/backend/ipc/ipc_nsi_handler.js#L243>
>>     >
>>     >      this._ipcMain.add('nsi_getChapterText', async (moduleCode,
>>     > bookCode, chapter) => {
>>     >        if (!this._useWebApi) {
>>     >          return this._nsi.getChapterText(moduleCode, bookCode,
>>     > chapter); } else {
>>     >          return await
>>     >
>>     this.getFromWebApi(`/module/${moduleCode}/chaptertext/${bookCode}/${chapter}`);
>>     >        }
>>     >      });
>>     >
>>     > Based on the switch useWebApi (currently just a constant) I can
>>     > switch between the "local version" and the "remote version".
>>     > The interface is compatible, because both the local version and
>>     the
>>     > remote version pull data from node-sword-interface and that
>>     already
>>     > returns JSON as of today.
>>     >
>>     > I ended up with a test version of Ezra Bible App that would load
>>     > module lists and offer the regular browsing capabilities as the
>>     > normal "offline" variant.
>>     > The performance in the UI for regular Bible browsing is nearly the
>>     > same.
>>     >
>>     > The use case that I see is to install a bunch of popular modules on
>>     > the server side for different languages and offer these to the user
>>     > based on quick "online access" right after installing the app.
>>     >
>>     > I am also interested how this behaves when the internet
>>     connection is
>>     > slower. I'll report some findings once I have them. It should
>>     be easy
>>     > to simulate that now based on the developer tools built into
>>     Electron.
>>     >
>>     > Right now this is an experiment. I'll explore a bit more and if
>>     this
>>     > turns out useful, I may think about integrating this into Ezra.
>>     >
>>     > Best regards,
>>     > Tobias
>>     >
>>
>>     _______________________________________________
>>     sword-devel mailing list: sword-devel at crosswire.org
>>     <mailto:sword-devel at crosswire.org>
>>     http://crosswire.org/mailman/listinfo/sword-devel
>>     <http://crosswire.org/mailman/listinfo/sword-devel>
>>     Instructions to unsubscribe/change your settings at above page
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org 
>> <mailto:sword-devel%40crosswire.org>
>> http://crosswire.org/mailman/listinfo/sword-devel 
>> <http://crosswire.org/mailman/listinfo/sword-devel>
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20240817/372ffa0a/attachment.htm>


More information about the sword-devel mailing list